Когда количество записей в хеш-таблице превышает произведение коэффициента загрузки и текущей емкости, хеш-таблица повторно хешируется (то есть перестраиваются внутренние структуры данных).
Я обнаружил, что Временная сложность изменения размера Java HashMap составляет O(n).
Итак, я попробовал этот код:
HashMap m = new HashMap(); // 67108864
Field tableField = HashMap.class.getDeclaredField("table");
tableField.setAccessible(true);
Object[] table = (Object[]) tableField.get(m);
double start = System.nanoTime();
for (int i = 0; i < 40000000; i++) {
m.put(i, 2);
}
System.out.println("Time " + (System.nanoTime() - start));
Случай 1: HashMap m = new HashMap() (сделано четыре раза):
Time 1.8827853524E10
Time 1.8862155334E10
Time 1.9829058308E10
Time 2.1675438455E10
Вариант 2: HashMap m = new HashMap(67108864):
Time 2.3358127475E10
Time 2.333575721E10
Time 2.3417082861E10
Time 2.3754431804E10
Должно ли время во втором случае быть лучше, чем в первом?
РЕДАКТИРОВАТЬ :
Я просто добавляю этот аргумент добавления моего jvm: -Xms14g -Xmx17g -verbose:gc
Случай 1: HashMap m = new HashMap():
Time 1.77303802E9
Time 1.814113689E9
Time 2.025116611E9
Time 1.725265406E9
Вариант 2: HashMap m = new HashMap(67108864):
Time 1.139675599E9
Time 1.128597762E9
Time 1.162575164E9
Time 1.12267688E9
Итак, я предполагаю, что сборщик мусора сделал эти различия во времени, но я не знаю, почему случай 2 занял больше времени в GC, чем случай 1.