можете использовать и другое число (например 2, 3, 5, 7, итд).
можно даже не простое, а можно и вообще его не использовать. но в таком случае можно столкнуться с проблемами с работой классов с таким hashCode в коллекциях, алгоритм которых построен на использовании hashCode-ов.
почему именно 31 - так это потому, что умножая на 31 мы получаем сравнительно неплохой разброс значений. не слишком большой и не слишком маленький. таким образом, становится легче гарантировать рассчитывать на то, что разные объекты будут иметь разный хешкод. и что два разных объекта, у которых получится одинаковый хешкод - будет сравнительно редкое явление.
там, кажется, было несколько задач на написание своих хешкодов. может курсе на коллекции, а не на многопоточность... ну ничего, потом до них дойдете и разберетесь получше уже :)
Подойдет любое простое число (т.е. которое делится только на самое себя), но выбрали именно 31. Других особых причин нет. По крайней мере это то что я знаю.
гарантироватьрассчитывать на то, что разные объекты будут иметь разный хешкод. и что два разных объекта, у которых получится одинаковый хешкод - будет сравнительно редкое явление. там, кажется, было несколько задач на написание своих хешкодов. может курсе на коллекции, а не на многопоточность... ну ничего, потом до них дойдете и разберетесь получше уже :)