Потому что это две разные ссылки на объекты. ==сравните ссылки, а не hashCodeрезультаты.

Чтобы получить желаемый результат, вы можете переопределить equalsметод в своем классе и использовать, h1.equals(h2)чтобы увидеть, эквивалентны ли они. Здесь вы можете использовать результат, hashCodeчтобы упростить оценку равенства сравниваемых объектов (это не означает, что два объекта с одинаковым хеш-кодом равны).

Но обратите внимание, что даже если объекты имеют одинаковые значения hashCodeи являются эквивалентными по определению equalsметода, они являются разными ссылками, которые занимают другое место в куче.

Как указывает @ZouZou, hashCodeравенство не означает равенство объектов. Сказав это, вы даже не сравниваете предметное равенство. Сравнение двух объектов ==- это проверка на равенство ссылок, которую вы почти никогда не должны использовать, если только вы действительно не знаете, что делаете.

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

Подумайте об этом ... Хеш-код является хэш-кодом int, поэтому существует только 2 ³² возможных значения. Но сколько есть возможных String? Много, много больше 2 ³² . (Поскольку у каждого charесть 2 ¹⁶ возможных значений, существует 2 ⁴⁸ возможных Strings длины три, и число увеличивается с увеличением длины Strings.) Следовательно, невозможно создать схему, в которой два Strings всегда равны, если их хэш-коды равны. То же самое верно для большинства других объектов (хотя класс с относительно небольшим числом возможных значений может быть установлен с уникальным хеш-кодом для каждого значения).

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