Почему при переопределении hashCode чаще всего используют просто число 31?

Почему при переопределении hashCode чаще всего используют просто число 31? Где-то слышал, что это число, было выбрано, с математической точки зрения, так как оно обеспечивает равномерное распределение hashCode функции, что обеспечивает минимальную вероятность появления коллизий.

Ответ

В Effective Java Джошуа Блоха говорится, что:
31 было выбрано так как это нечётное простое число.
Если вопрос в том, почему именно 31, то это потому что операция умножения может быть заменена сдвигом и вычитанием для повышения производительности: 31 * i == (i << 5) - i. Современные виртуальные машины делают такого рода оптимизации автоматически.
Можно так же почитать это
Из оставшихся четырех я, наверное, выберу P(31), так как его дешевле вычислять на RISC архитектурах (потому что 31 разность двух степеней двойки). Р(33) так же дешева для вычисления, но его производительность незначительно хуже, и 33 - составное, что заставляет меня нервничать.