Процесс повторного хэширования в hashmap или hashtable

Как выполняется процесс повторного хэширования в hashmap или hashtable, когда размер превышает значение maxthreshold?

все пары просто скопированы в новый массив ведер?

EDIT:

Что происходит с элементами в том же ведре (в связанном списке) после повторного хэширования? Я имею в виду, останутся ли они в том же ведре после переиздания?

12
algorithm hash hashmap hashtable java

3 ответов

максимальный порог в вопросе называется коэффициентом загрузки.

желательно иметь коэффициент нагрузки около 0,75. Коэффициент загрузки определяется как (m / n), где n-общий размер хэш-таблицы, а m-предпочтительное количество записей, которые могут быть вставлены перед увеличением размера базовой структуры данных.

перефразирование можно сделать в двух случаях:

  1. когда настоящий коэффициент m'/n увеличивает за пределами коэффициент нагрузки

  2. m'/n отношение падает до очень низкого значения, скажем, 0.1

в обоих случаях m ' - текущее количество записей. Кроме того, оба случая требуют переноса существующих записей в большую или меньшую хэш-таблицу.

в контексте вопроса rehashing-это процесс применения хэш-функции к записям, чтобы переместить их в другую хэш-таблицу. Можно использовать хэш-функцию, которая использовалась ранее или используйте новую функцию.

пожалуйста, обратите внимание: Rehashing также делается, когда происходит столкновение. (Это также способ обработки столкновений.)

чтобы добавить дополнительный контекст и подробное обсуждение, пожалуйста, посетите мой блог Основы Майнинга

17

перезапись хэш-карты выполняется, когда количество элементов на карте достигает максимального порогового значения.

обычно значение коэффициента нагрузки составляет 0,75, а значение начальной емкости по умолчанию-16. Как только количество элементов достигает или пересекает 0.75 раз емкость, происходит повторное отображение карты. В этом случае, когда количество элементов равно 12, происходит повторное отображение. (0.75 * 16 = 12)

при повторном хэшировании возникает новая хэш-функция или даже тот же хэш функция может использоваться, но могут изменяться ведра, в которых присутствуют значения. В основном, когда происходит перестановка, количество ведер приблизительно удваивается и, следовательно, изменяется новый индекс, при котором значение должно быть поставлено.

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

Если есть несколько потоков, обрабатывающих одну и ту же хэш-карту, это может привести к бесконечному циклу.

подробное объяснение того, как происходит бесконечный цикл в приведенном выше случае, можно найти здесь:http://mailinator.blogspot.hu/2009/06/beautiful-race-condition.html

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

7

хеширование – перефразирование и гонки

в основном при создании коллекции хэш-карт назначьте ей размер по умолчанию (10). На более позднем этапе, когда элементы добавляются в карту и после определенного этапа, когда вы приближаетесь к своей первоначальной определенной емкости, требуется перефразировать, чтобы сохранить производительность.

для коллекции определен LoadFactor (говорят, что это хорошо .75) и это определяет хороший индекс для времени и пространство.

  • больший коэффициент нагрузки => меньшее потребление пространства, но более высокие запросы
  • меньший коэффициент нагрузки => большее потребление пространства по сравнению с требуемым no элементов.

спецификация Java предполагает, что хорошее значение loadfactor .75

следовательно, предположим, что у вас есть максимальное требование для хранения 10 элементов в хэше, а затем учитывая хороший Loadfactor .75 = перезапись произойдет после добавления 7 элементов в коллекцию. В случае если ваше требование в этом случае не будет присоединяться к 7, то повторное повторение никогда не произойдет.

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

состояние гонки: при повторном выполнении внутренних элементов, которые хранятся в связанном списке для данного ведра. Они получают обратное в порядке. Предположим, есть два потока сталкиваются с условием гонки в то же время, то есть шансы второго therad может идти в бесконечном цикле во время обхода, так как порядок был изменен.

6