Почему java HashMap изменяет размер или reha sh не использует постепенный подход, как Redis

Question

Мне просто интересно, почему процесс перекомпоновки JDK HashMap не использует постепенный подход в качестве Redis. Хотя расчет JDK HashMap по reha sh довольно элегантен и эффективен, он все равно займет заметное время, когда число элементов в исходном HashMap содержит довольно много записей. Я не опытный пользователь java, поэтому я всегда полагаю, что необходимо учитывать java дизайнеров, которые выходят за пределы моих когнитивных способностей. Постепенное повторение sh, как и в Redis, может эффективно распределять рабочую нагрузку по каждому положению, удалению или вставке в HashMap, что может значительно сократить время изменения размера / перефразировки. И я также сравнил два метода ha sh, которые, на мой взгляд, не ограничивают Jdk от постепенной перефразировки. Надеюсь, что кто-то может дать подсказку или вдохновение. Заранее большое спасибо.

Answer 1

Если вы думаете о затратах и ​​выгодах от дополнительной перефразировки для чего-то вроде HashMap, то получается, что затраты не являются незначительными, и выгода не так велика, как вы могли бы.

An пошаговая перефразировка HashMap:

• В среднем использует на 50% больше памяти, поскольку при инкрементной перефразировке необходимо сохранять старую и новую таблицы; и
• имеет несколько более высокие вычислительные затраты на операцию. Также:
• Перефразировка еще не является полностью инкрементной, потому что выделение нового массива таблицы ha sh должно быть выполнено все сразу; поэтому
• Нет никаких улучшений в асимптотике c сложности любой операции. И наконец:
• Почти ничего, что действительно требовало бы постепенной перефразировки, вообще невозможно реализовать в Java из-за непредсказуемых пауз G C, так зачем беспокоиться?