Qual é o contrato entre equals e hashCode, e o que quebra se você errar?

Se dois objetos são iguais por equals, eles precisam retornar o mesmo hashCode; objetos diferentes podem compartilhar um hash, mas idealmente não compartilham. Quebre isso e as coleções baseadas em hash se comportam mal: um objeto colocado num HashMap fica inalcançável porque a busca vai para outro bucket. equals também precisa ser reflexivo, simétrico, transitivo e consistente, e mutar um campo usado no hash depois da inserção perde a entrada com a mesma eficiência.

A regra é unidirecional: objetos iguais precisam ter hash codes iguais, mas hash codes iguais não implicam igualdade, e é por isso que o mapa ainda chama equals dentro do bucket. Se eu sobrescrevo equals e esqueço hashCode, dois objetos que são iguais caem em buckets diferentes, então eu posso colocar algo num HashSet e depois ter contains retornando false para um objeto idêntico. A versão mais sutil é a mutação. Se um campo usado no hash muda depois que o objeto já está no set, a entrada agora está no bucket errado e está efetivamente perdida, o que aparece como vazamento porque ela nunca poderá ser removida também. Na prática eu uso records para tipos de valor, assim os dois são gerados e ficam consistentes. Para entidades JPA eu tomo cuidado, porque usar um id gerado significa que equals muda quando a entidade é persistida, então uma entidade num HashSet antes do flush se comporta de forma diferente depois. Eu uso uma chave natural ou de negócio estável quando existe uma, e no resto evito colocar entidades não salvas em coleções baseadas em hash.