Зачем использовать простое число в hashCode?

Мне просто интересно, почему эти простые числа используются в hashCode()методе класса ? Например, при использовании Eclipse для генерации моего hashCode()метода всегда используется простое число 31:

public int hashCode() {
     final int prime = 31;
     //...
}

Ссылки:

Вот хороший учебник по Hashcode и статья о том, как работает хеширование, которую я нашел (C #, но концепции переносимы): Руководство и правила Эрика Липперта для GetHashCode ()

Потому что вы хотите, чтобы число, на которое вы умножали, и количество блоков, в которые вы вставляете, имели ортогональные простые факторизации.

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

31 - достаточно большое простое число, которое вряд ли будет делиться им на количество сегментов (и на самом деле современные реализации Java HashMap поддерживают количество сегментов в степени 2).

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

Это часто имеет место при работе с областями памяти. Например, все 32-разрядные целые числа выровнены по адресам, кратным 4. Посмотрите на таблицу ниже, чтобы визуализировать эффекты использования простого и не простого модуля:

Input       Modulo 8    Modulo 7
0           0           0
4           4           4
8           0           1
12          4           5
16          0           2
20          4           6
24          0           3
28          4           0

Обратите внимание на почти идеальное распределение при использовании простого модуля против не простого модуля.

Однако, хотя приведенный выше пример в значительной степени надуманный, общий принцип заключается в том, что при работе с шаблоном входных данных использование модуля простых чисел даст наилучшее распределение.

Во что бы то ни стало, Effective Java 2nd Edition отказывается от математической проблемы и просто говорит, что причина выбора 31:

• Потому что это нечетное простое число, и это «традиционно» использовать простые числа
• Это также на единицу меньше, чем степень два, что позволяет для побитовой оптимизации

Вот полная цитата из пункта 9: Всегда переопределять hashCodeпри переопределенииequals :

Значение 31 было выбрано, потому что это нечетное простое число. Если бы оно было четным и умножение было переполнено, информация была бы потеряна, так как умножение на 2 эквивалентно сдвигу. Преимущество использования прайма менее очевидно, но оно традиционно.

Хорошим свойством 31 является то, что умножение может быть заменено сдвигом ( §15.19 ) и вычитанием для лучшей производительности:

 31 * i == (i << 5) - i

Современные виртуальные машины выполняют такую ​​оптимизацию автоматически.

---

Хотя рецепт в этом пункте дает достаточно хорошие хеш-функции, он не дает современных хеш-функций, и библиотеки Java не предоставляют такие хеш-функции, как в выпуске 1.6. Написание таких хеш-функций - тема исследования, которую лучше оставить математикам и теоретикам.

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

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

Смежные вопросы

• Java hashCode из одного поля - рецепт плюс пример использования сборщиков Apache Commons Lang
• Неправильно ли определять хеш-код объекта как сумму, умножение, хеш-коды всех переменных класса?
• Руководство абсолютного новичка по битрейфингу?

Я слышал, что 31 был выбран так, чтобы компилятор мог оптимизировать умножение до 5 битов влево и затем вычесть значение.

Вот цитата немного ближе к источнику.

Это сводится к:

• 31 простое, что уменьшает столкновения
• 31 производит хорошее распределение, с
• разумный компромисс в скорости

Сначала вы вычисляете значение хеша по модулю 2 ^ 32 (размер an int), поэтому вы хотите получить что-то относительно простое до 2 ^ 32 (относительно простое означает, что общих делителей нет). Для этого подойдет любое нечетное число.

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

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

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

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

Но когда данные не случайны, происходят странные вещи. Например, рассмотрим числовые данные, которые всегда кратны 10.

Если мы используем мод 4, мы находим:

10 мод 4 = 2

20 мод 4 = 0

30 мод 4 = 2

40 мод 4 = 0

50 мод 4 = 2

Таким образом, из 3 возможных значений модуля (0,1,2,3) только 0 и 2 будут иметь столкновения, что плохо.

Если мы используем простое число, такое как 7:

10 мод 7 = 3

20 мод 7 = 6

30 мод 7 = 2

40 мод 7 = 4

50 мод 7 = 1

и т.д

Мы также отмечаем, что 5 не является хорошим выбором, но 5 простое, потому что все наши ключи кратны 5. Это означает, что мы должны выбрать простое число, которое не делит наши ключи, выбор большого простого числа обычно достаточно.

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

31 также специфичен для Java HashMap, который использует int как тип хеш-данных. Таким образом, максимальная емкость 2 ^ 32. Нет смысла использовать большие простые числа Ферма или Мерсенна.

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