Quel est le contrat entre equals et hashCode, et qu'est-ce qui casse si vous vous trompez ?

Si deux objets sont égaux selon equals, ils doivent renvoyer le même hashCode ; des objets différents peuvent partager un hash mais idéalement non. Cassez ce contrat et les collections à base de hash déraillent : un objet placé dans une HashMap devient introuvable parce que la recherche va dans un autre bucket. equals doit aussi être réflexif, symétrique, transitif et cohérent, et modifier un champ utilisé dans le hash après l'insertion perd l'entrée tout aussi efficacement.

La règle est à sens unique : des objets égaux doivent avoir des hash codes égaux, mais des hash codes égaux n'impliquent pas l'égalité, ce qui explique qu'une map appelle quand même equals à l'intérieur du bucket. Si je redéfinis equals et que j'oublie hashCode, deux objets égaux atterrissent dans des buckets différents, donc je peux mettre quelque chose dans un HashSet puis voir contains renvoyer false pour un objet identique. La version plus subtile, c'est la mutation. Si un champ utilisé dans le hash change après que l'objet est dans un set, l'entrée est désormais dans le mauvais bucket et elle est perdue de fait, ce qui se manifeste comme une fuite mémoire puisqu'elle ne peut plus être retirée non plus. En pratique j'utilise des records pour les types valeur, comme ça les deux sont générés et cohérents. Pour les entités JPA je fais attention, parce qu'utiliser un id généré signifie que equals change quand l'entité est persistée, donc une entité dans un HashSet avant le flush ne se comporte plus pareil après. J'utilise une clé naturelle ou métier stable quand il y en a une, et sinon j'évite de mettre des entités non sauvegardées dans des collections à base de hash.