All 15 Collections Framework questions
More in Collections Framework
What is the Java Collections Framework, and what are the core interfaces (List, Set, Map, Queue) at its foundation? What is the difference between the Iterable and Iterator interfaces, and how does the enhanced for-each loop rely on them? What are the key performance differences between ArrayList and LinkedList for common operations (random access, insertion/removal at various positions), and when would you choose one over the other? What is the difference between fail-fast and fail-safe iterators in the Collections Framework, and which collections use each? What are the immutable collection factory methods (List.of(), Set.of(), Map.of()) introduced in Java 9, and how do they differ from Collections.unmodifiableList()? What is the purpose of the Deque interface, and how does it unify both stack (LIFO) and queue (FIFO) behavior in a single interface? What is the purpose of the Collections utility class's synchronization wrappers (Collections.synchronizedList(), etc.), and how do they differ from genuinely concurrent collections like ConcurrentHashMap? How does PriorityQueue work internally (as a binary heap), and what ordering does it use by default versus with a custom Comparator? How does HashMap's internal implementation work (hashing, bucket array, treeification), and how did its collision-handling strategy change in Java 8? How do you choose between HashMap, LinkedHashMap, and TreeMap based on their different ordering guarantees and performance characteristics?
Advertisement
Back to results for “Collections”
Java › Collections Framework

What is the contract between equals() and hashCode() that a custom class must satisfy to work correctly as a HashMap key or HashSet element?

Intermediate

Answer

Any two objects considered equal via equals() MUST return the identical hashCode() value (though the converse isn't required -- unequal objects may share a hash code, called a collision, which is handled but should be rare for good performance); violating this contract (overriding equals() without also overriding hashCode() consistently) causes silently broken behavior in hash-based collections, since a HashMap uses hashCode() to locate the correct bucket first, then equals() to confirm the exact match within that bucket -- if two "equal" objects hash differently, a HashMap may fail to locate an entry that logically should be found, appearing to have simply lost data.
public class Point {
    private final int x, y;
    // constructor omitted

    @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);  // MUST be consistent with equals()
    }
}
Real-world example A bug report describing a HashSet<Point> that appears to allow "duplicate" points is traced to a Point class overriding equals() (correctly comparing x/y coordinates) but forgetting to also override hashCode(), causing two logically equal Point instances to land in different buckets and never be recognized as duplicates by the HashSet.

Common follow-ups: What happens if hashCode() is overridden but equals() is not, in terms of contract violation risk?;Why does Object's default hashCode() implementation (based on memory address) become invalid once equals() is overridden?

equals() hashCode() & toString() Contracts;Diagnostics & Performance
All 15 Collections Framework questions