Wie lautet der Vertrag zwischen equals und hashCode, und was geht kaputt, wenn du ihn verletzt?

Wenn zwei Objekte laut equals gleich sind, müssen sie denselben hashCode liefern; ungleiche Objekte dürfen sich einen Hash teilen, tun es idealerweise aber nicht. Verletzt du das, spielen hash-basierte Collections verrückt: ein Objekt, das du in eine HashMap gelegt hast, wird unerreichbar, weil das Lookup in einem anderen Bucket landet. equals muss außerdem reflexiv, symmetrisch, transitiv und konsistent sein, und ein Feld nach dem Einfügen zu ändern, das im Hash steckt, verliert den Eintrag genauso zuverlässig.

Die Regel gilt nur in eine Richtung: gleiche Objekte müssen gleiche Hash-Codes haben, gleiche Hash-Codes bedeuten aber keine Gleichheit, weshalb eine Map innerhalb des Buckets trotzdem equals aufruft. Überschreibe ich equals und vergesse hashCode, landen zwei gleiche Objekte in unterschiedlichen Buckets, ich kann also etwas in ein HashSet legen und contains liefert für ein identisches Objekt false. Die subtilere Variante ist Mutation. Ändert sich ein Feld, das im Hash steckt, nachdem das Objekt im Set liegt, sitzt der Eintrag im falschen Bucket und ist praktisch verloren, was sich als Leak zeigt, weil er auch nie mehr entfernt werden kann. In der Praxis nehme ich Records für Value Types, dann werden beide generiert und sind konsistent. Bei JPA-Entities bin ich vorsichtig, denn eine generierte id bedeutet, dass sich equals ändert, sobald die Entity persistiert wird, eine Entity im HashSet verhält sich also vor dem Flush anders als danach. Ich nehme einen stabilen fachlichen Schlüssel, wenn es einen gibt, und lege ungespeicherte Entities sonst gar nicht erst in hash-basierte Collections.