hashCode equals Contract Java | Fresher Interview
Fast recall
Quick revision
Core answer
equals returns true), they must have the same `hashCode()`; and equals must be consistent (reflexive, symmetric, transitive). HashMap relies on this - it finds the bucket via hashCode, then confirms the key via equals. Override both together or lookups silently fail: equal objects in different buckets are never found.Whether you know overriding one without the other breaks HashMap lookups
Overriding equals but not hashCode (or vice versa), causing 'present' keys to go missing
Explain the bucket-then-equals lookup path and why unequal hashCodes for equal objects break it
Interview-ready guide
Interview answer
The contract between hashCode and equals is what makes hash-based collections work.
The main rule is: if two objects are equal according to equals, they must return the same hashCode. The reverse isn't required, two objects with the same hashCode don't have to be equal, because collisions are allowed and resolved by equals. And equals itself has to be well behaved: reflexive, symmetric, transitive, and consistent.
Why does HashMap care so much? Because a lookup is a two-step process. First it uses the key's hashCode to figure out which bucket the entry should be in.
Then, within that bucket, it uses equals to find the exact matching key. Now imagine I override equals but forget to override hashCode. Two objects that I consider equal will inherit Object's default hashCode, which is based on object identity, so they'll almost certainly produce different hash codes and get sent to different buckets.
When I look up a key, the map computes a different bucket than where I stored it, doesn't find it, and returns null, even though I clearly put it in. The key effectively disappears. That's the classic bug.
So the rule I follow is to always override both together, with logic based on the same fields. In modern Java the easiest way is to use a record, which auto-generates both consistently, or to let the IDE or Objects dot hash generate them. I also avoid using mutable fields in hashCode, because if a key's fields change after it's in the map, its hash changes and the entry becomes unreachable.
hashCode equals Contract Java | Fresher Interview
Direct Answer
The contract: if two objects are equal (equals returns true), they must have the same hashCode(); and equals must be consistent (reflexive, symmetric, transitive). HashMap relies on this - it finds the bucket via hashCode, then confirms the key via equals. Override both together or lookups silently fail: equal objects in different buckets are never found.
Code Example
// BROKEN: equals overridden, hashCode NOT -> lookup fails
class BadId {
final int id; BadId(int id){ this.id = id; }
public boolean equals(Object o){ return o instanceof BadId b && b.id==id; }
// inherits Object.hashCode() -> different per instance!
}
Map<BadId,String> m1 = new HashMap<>();
m1.put(new BadId(7), "X");
System.out.println(m1.get(new BadId(7))); // null! wrong bucket
// CORRECT: record generates equals AND hashCode together
record GoodId(int id) {}
Map<GoodId,String> m2 = new HashMap<>();
m2.put(new GoodId(7), "X");
System.out.println(m2.get(new GoodId(7))); // "X"
Common Mistakes & Pitfalls
- Override equals only: equal objects get different hashCodes -> map lookups miss.
- Override hashCode only: objects land in the right bucket but
equalsrejects them. - Mutable fields in hashCode: changing them after insertion makes the entry unreachable.
- Hand-writing inconsistently: prefer
record, IDE generation, orObjects.hash(...).
Check your understanding
Answer these without looking back at the article.
- What happens if you only override equals but not hashCode?
- What is the default implementation of hashCode in Java?
- How does HashSet ensure uniqueness?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.