Оптимизация памяти Java Collectors.toMap

Будет ли вторая реализация включать несколько изменений размера HashMap или оптимизирована для выделения достаточно памяти?

В вашем коде первый. См. https://stackoverflow.com/a/51333961/139985

Стоит отметить, что для вашей текущей реализации:

1. Большая часть дополнительная память, потребляемая путем изменения размера, будет восстановлена ​​при следующем запуске GC.
2. После окончания collect вы все равно можете получить основной массив хэшей, который в два раза больше. Память «впустую» может составлять до 8 байтов на запись в таблице, но в среднем она будет 4 байта на запись.
3. Тем не менее, узлы ввода хешей будут самым большим потребителем памяти в a HashMap. Каждая запись потребляет примерно 32 байта ... в дополнение к пространству, используемому для представления ключа и значения.

(Приведенные выше числа предполагают 64-битные ссылки.)

---

В качестве альтернативы, если вы используете перегрузку аргумента 4 в toMap(), вы можете предоставить Supplier для создания Map для заполнения. Это позволяет сделать следующее:

• Выделить HashMap с начальной мощностью, достаточной для того, чтобы избежать изменения размера, но не слишком большого.
• Используйте (гипотетический) альтернативная реализация Map, которая использует меньше памяти для каждой записи, чем HashMap.
• Создайте оболочку, чтобы заполнить объект, похожий на карту, который не реализует Map<K,V> ... для вашего K и V. (Например, вы могли бы использовать TLongObjectHashMap в библиотеке GNU Trove.)

(В последних двух случаях целью является найти Map или «map-like «класс, который использует меньше памяти (для ваших типов K и V), но все же имеет соответствующую производительность для поиска.)

Подводя итог тому, что говорили все остальные и добавив немного, вот способ сделать это, используя пользовательский Collector. Однако вы должны иметь в виду две вещи:

1. Продолжая мысль о Stephen C из его ответа , вы действительно не должны быть обеспокоены оптимизацией таких случаев, пока вы не узнаете, что это действительно узкое место в вашей заявке. Как сказал Дональд Кнут , «преждевременная оптимизация - это корень всего зла».
2. Поскольку shmosel указал в комментарии, Collector, что выделяет HashMap с предопределенным размером, будет перераспределять, если указанный Collector используется в параллельном режиме. Поэтому Collector, который я предлагаю, не поддерживает параллельный сбор.

Сказав это, вы можете записать следующий общий Collector s:

public class ExtraCollectors {

    public static <T, K, V> Collector<T, ?, HashMap<K, V>> toSizedMap(
            Function<? super T, ? extends K> keyMapper, Function<? super T, ? extends V> valueMapper, int size) {
        return toSequentialMap(
                () -> com.google.common.collect.Maps.newHashMapWithExpectedSize(size),
                keyMapper, valueMapper, Collector.Characteristics.UNORDERED
        );
    }

    public static <T, K, V, M extends Map<K, V>> Collector<T, ?, M> toSequentialMap(
            Supplier<M> mapSupplier, Function<? super T, ? extends K> keyMapper,
            Function<? super T, ? extends V> valueMapper, Collector.Characteristics... characteristics) {
        return Collector.of(
                mapSupplier,
                (map, element) -> map.merge(
                        keyMapper.apply(element), valueMapper.apply(element), ExtraCollectors::mergeUnsupported
                ),
                ExtraCollectors::combineUnsupported,
                characteristics
        );
    }

    private static <T> T mergeUnsupported(T valueA, T valueB) {
        throw new UnsupportedOperationException("This Collector does not support merging.");
    }

    private static <A> A combineUnsupported(A accumulatorA, A accumulatorB) {
        throw new UnsupportedOperationException("This Collector does not support parallel streams.");
    }
}

Обратите внимание, что я использовал Guava Maps.newHashMapWithExpectedSize , чтобы вы получили HashMap с нужным вам размером (примерно то, что Andreas объяснил в своем комментарии к вашему вопросу ). Если у вас нет зависимости от Guava (и вы не хотите этого делать), вы можете просто скопировать метод Maps.capacity на вашу кодовую базу.

Используя метод ExtraCollectors.toSizedMap(), определенный выше, ваш метод преобразования будет выглядеть следующим образом:

Map<Long, KeyedObject> listToMap(List<? extends KeyedObject> objs) {
    return objs.stream().collect(ExtraCollectors.toSizedMap(KeyedObject::getKey, obj -> obj, objs.size()));

}

Тем не менее, если вам действительно нужна максимальная производительность (по цене повторного использования), вы можете пропустить API Stream, и примените ваше решение 1, но с Maps.newHashMapWithExpectedSize, чтобы получить размер HashMap.