Разработка метода hashCode Java

Как это значение поможет уменьшить количество столкновений?

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

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

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

Что он имеет в виду, говоря, что точное значение, возвращаемое hashCode, является функцией значения экземпляра?

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

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

См. Этот пример:

    String a = "Abc";
    String b = "Abc";
    String c = "Pqr";
    System.out.println(" "+a.hashCode()+" "+b.hashCode()+" "+c.hashCode());

Выход: 65602 65602 80497

Это ясно показывает, что hashCode () строки зависит от значений.

Выдержка из документации hashCode ():
int java.lang.String.hashCode ()

Возвращает хэш-код для этой строки. Хэш-код для объекта String вычисляется как

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

с использованием арифметики int, где s [i] - i-й символ строки, n - длина строки, а ^ указывает возведение в степень. (Хеш-значение пустой строки равно нулю.)

Реализация hashCode в Effective Java специально инструктирует вас выбрать ненулевое значение для начального значения результата. Что касается вашего второго вопроса, hashCode предполагается для получения того же значения, когда внутреннее состояние, используемое для равных сравнений объекта, одинаково. Таким образом, тот факт, что вы получите одно и то же значение, когда все переменные экземпляра равны нулю, выполняет контракт hashCode. Обратите внимание, что весь подзаголовок - «Всегда переопределять hashCode, когда вы переопределяете равно».

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

Что касается вашего второго вопроса, я не претендую на большой опыт разработки хеш-кода, однако я считаю, что он имеет в виду, что определенные объекты могут возвращать только одно значение хеша (например, синглтон).

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

В любом случае указывать возвращаемое значение или полагаться на указанное возвращаемое значение - плохая идея.

Прежде всего хочу сказать очень важную вещь, которую часто нечетко формулируют:

Внедрение хэш-кода для БОЛЬШИНСТВА СЛУЧАЕВ НЕ ВАЖНО. Это сводится только к проблеме производительности. Поэтому, если у вас есть проблема с хэш-кодом и идентификатором объекта, просто верните -1. У вас будет низкая производительность, но надежная и правильная реализация. Но пока у вас не будут тысячи объектов, использующих хэш-код, вы не заметите низкой производительности. кстати: «Столкновение» выглядит значимым словом в контексте хэш-кода. Да, но только если производительность действительно является проблемой. «Столкновение» значений хэш-кода не означает, что ваша программа работает некорректно. Это означает, что ваша программа может работать медленнее. Поскольку доступ с ключом к карте вызовет последовательную итерацию по объектам с тем же хэш-кодом. В высокопроизводительных средах это может быть проблемой. В большинстве случаев нет.

Но что ВАЖНО, если вы переопределяете хэш-код: вы должны реализовать его ПРАВИЛЬНО. Таким образом, определение всегда должно выполняться: если equals возвращает true, хэш-код должен возвращать то же значение.

Еще одна вещь: хотя вы случайно не столкнетесь с проблемами с этим, вычисление хэш-кода на неизменяемых значениях - плохая идея. Это связано с тем, что после использования хэш-кода объект помещается в специальную позицию на «Карте». При изменении значений, от которых зависит хэш-код, этот объект может быть утерян или станет труднодоступным. Это повлияет на правильность вашей программы.

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