Java, Object.hashCode () результат, постоянный через весь JVMs/Systems?

Из API

Общий контракт hashCode:

• Каждый раз, когда он вызывается для одного и того же объекта более одного раза во время выполнения приложения Java, метод hashCode должен последовательно возвращает то же целое число, при условии, что никакая информация, используемая в равных сравнениях объекта, не изменена. Это целое число не обязательно должно оставаться согласованным от одного выполнения приложения к другому выполнению того же самого приложения.
• Если два объекта равны в соответствии с методом equals (Object), то вызов метода hashCode для каждого из двух объектов должен привести к тот же целочисленный результат.
• Не требуется, чтобы, если два объекта не равны в соответствии с методом equals (java.lang.Object), то вызов метода hashCode для каждого из двух объектов должен давать различные целочисленные результаты. Однако, программист должен знать, что получение различных целочисленных результатов для неравных объектов может улучшить производительность хэш-таблиц.

Насколько это разумно практично, метод hashCode, определенный классом Object, действительно возвращает отдельные целые числа для отдельных объектов. (Обычно это реализуется путем преобразования внутреннего адреса объекта в целое число, но этот метод реализации не требуется для языка программирования JavaTM.)

Нет, результатом hashCode () является только константа во время одного выполнения. Не следует ожидать, что результат функции будет одинаковым между исполнениями, не говоря уже о разных версиях JRE или платформах.

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

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

Если вы ссылаетесь исключительно на Sun Vm, можно утверждать, что Sun не сломает - даже плохо запрограммированный - существующий код. итак "тест". hashCode () всегда будет возвращать точно 3556498 для любой версии Sun VM .

Если вы хотите намеренно выстрелить себе в ногу, продолжайте и полагайтесь на это. люди, которым нужно будет исправить ваш код, работающий на «виртуальной машине Nintendo Java Java для фена 2015», будут выкрикивать ваше имя по ночам.

Как уже отмечалось, для многих реализаций по умолчанию hashCode () возвращает адрес объекта. Очевидно, каждый раз при запуске программы это может быть разным. Это также согласуется с поведением equals () по умолчанию: два объекта равны, только если они являются одним и тем же объектом (где x и y оба ненулевые, x.equals (y) тогда и только тогда, когда x == y) .

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

Это не гарантируется, хотя трудно придумать разумный пример из реальной жизни.