If two objects are equal according to equals(), they must return the same hashCode(). The reverse isn't required — unequal objects may share a hash code (a collision), but equal objects must never have different hash codes, or hash-based collections like HashMap/HashSet will behave incorrectly (e.g., silently failing to find an existing entry).

Advanced7 min

AmazonGoogleMicrosoftFlipkartOracleAdobe

#equals()#hashCode()#Contract

What is the equals() and hashCode() contract in Java?

What Breaking It Actually Looks Like

Override equals() alone and put an object in a HashSet: the set uses hashCode() first to find the right bucket, then equals() to check within it — if hashCode() wasn't updated to match, a logically-equal object lands in the wrong bucket and contains(x) returns false even though an 'equal' object is sitting right there in the set.

equals() true → hashCode() MUST match · equals() false → hashCode() MAY match or differ

Consistent equals()/hashCode() Override

java

class Point {
    int x, y;

    @Override
    public boolean equals(Object o) {
        if (!(o instanceof Point p)) return false;
        return x == p.x && y == p.y;
    }

    @Override
    public int hashCode() {
        return Objects.hash(x, y);
    }
}

Interview Answer

The contract is one-directional: equal objects must produce equal hash codes, so that hash-based collections can find them consistently, but unequal objects are allowed to share a hash code — collisions are expected and handled internally. Breaking this contract (overriding equals() without hashCode()) is one of the most common real-world Java bugs, since objects silently 'disappear' from HashSets/HashMaps.