Что вызывает изменение размера ConcurrentHashMap

Question

Я считаю, что здесь изменен размер ConcurrentHashMap .

Я бы ожидал, что размер ConcurrentHashMap будет изменен, когда коэффициент загрузки достигнет определенного порога.

Однако яне вижу, как изменение размера, выполненное методом addCount, имеет какое-либо отношение к коэффициенту загрузки.

Каковы критерии изменения размера ConcurrentHashMap?Является ли фактор загрузки одним из них?

Answer 1

Из javadoc: ConcurrentHashMap:

Размер таблицы изменяется, если уровень занятости превышает процентное пороговое значение (номинально 0,75, но см. Ниже).

Таблица динамически расширяется, когда имеется слишком много коллизий (т. Е. Ключей, которые имеют разные хэш-коды, но попадают в один и тот же слот по модулю размера таблицы), с ожидаемым средним эффектом сохранения примерно двух бинов на отображение (соответствует 0,75порог коэффициента загрузки для изменения размера).При добавлении и удалении отображений может быть много отклонений от этого среднего, но в целом это поддерживает общепринятый компромисс между временем и пространством для хеш-таблиц.Однако изменение размера этой или любого другого вида хеш-таблицы может быть относительно медленной операцией.Когда это возможно, рекомендуется предоставить оценку размера в качестве необязательного аргумента конструктора {@code initialCapacity}.Дополнительный необязательный аргумент конструктора {@code loadFactor} предоставляет дополнительные средства для настройки начальной емкости таблицы путем указания плотности таблицы, которая будет использоваться при расчете объема пространства, выделяемого для данного числа элементов.Кроме того, для совместимости с предыдущими версиями этого класса конструкторы могут дополнительно указывать ожидаемый {@code concurrencyLevel} в качестве дополнительной подсказки для внутреннего определения размера.