equals and hashCode

Three things worth noticing.

The identity check first is a cheap win, not a correctness requirement.

Objects.equals handles nulls on both sides, which is why you use it rather than .equals directly on a field that might be null.

The same fields in both methods. If equals compares id and reference, hashCode uses id and reference. Nothing else. Drifting apart is how this breaks six months later.

instanceof or getClass

instanceof accepts subclasses. getClass() requires exactly the same class.

instanceof is friendlier and can break symmetry: a subclass may consider itself equal to its parent while the parent disagrees, and a.equals(b) differs from b.equals(a). getClass() is strict and rules out a subclass ever being equal to its parent, which is sometimes what you want.

Neither is simply correct. Pick one, know why, and be able to say it out loud.

Records already did this

That gives you equals, hashCode and toString over all components, consistently, for free.

If your class exists to hold values, a record is usually the right answer and it removes this entire category of bug. Reach for the handwritten version when you need something a record cannot give you, not by default.

The mutation trap

Even a correct pair breaks if you mutate a field the hash depends on after using the object as a key. The entry is in the map, in a bucket chosen by the old hash, and lookups compute the new one. It is unreachable and still occupying memory.

Keys should be immutable. That is the practical reason.

Under questioning

Expect: what is the contract, what happens if you override one and not the other, can two unequal objects share a hash code, and why should a key be immutable.

The answer that lands is not reciting the contract. It is explaining the two-step lookup, because everything else follows from it.