What happens if hashCode() is not overridden?

Why interviewers love this: it looks tiny, but it tests the equals/hashCode contract that keeps hash-based collections honest.

Question: What happens if hashCode() is not overridden?

Answer: If you do not override hashCode(), Java uses the version inherited from Object. That default is based on object identity, so two separate objects that are equal by your custom equals() may still get different hash values. In hash-based collections like HashMap and HashSet, that can make lookups fail or let duplicates slip in.

Interview-Ready Answer: I would say: if hashCode() is not overridden, the class keeps Object’s identity-based hash code. That means hash-based collections place the object using its identity hash, so if I override equals() but not hashCode(), logically equal objects can land in different buckets and lookups may fail. The key rule is: equal objects must always have the same hash code.

What actually happens under the hood

1. Every Java object already has a hashCode() method from Object.
2. The default implementation is identity-based: it is tied to that specific instance, not to the field values you care about. Java does not promise it is the memory address, only that it acts like a per-object identity value and stays stable for that object during one JVM run.
3. When you put a key into a HashMap or HashSet, Java uses the hash code to choose a bucket first. A bucket is a small slot inside the hash table.
4. When you search for a key, Java computes the hash code again, jumps to the same bucket, and then uses equals() to confirm whether the candidate really matches.
5. If two objects are logically equal by equals() but produce different hash codes, they may go to different buckets, so the collection never even compares them and the lookup fails.
6. If you do not override equals() either, then equality is just reference equality, so the default hashCode() and default equals() still agree with each other; the collection works, but only the exact same object matches.

The contract interviewers want

Java’s rule is simple: if a.equals(b) is true, then a.hashCode() == b.hashCode() must also be true. The reverse is not required: two different objects may share a hash code. That is called a collision.

Why this matters in practice

1. Insertion: a key is stored in the bucket chosen by its hash code.
2. Lookup: the same hash computation happens again.
3. Bucket scan: if the bucket is small, Java checks a few candidates with equals().
4. Miss: if the object lands in the wrong bucket, the search stops early and returns null or false.

Performance-wise, a good hash gives average O(1) insert and lookup. With many collisions, operations degrade toward O(n); in Java 8 and later, a very crowded bucket can become a tree bin, which improves that worst case to about O(log n) for that bucket. That treeification kicks in only when the table is large enough, typically with a bucket size around 8 and a capacity of at least 64; it can switch back down when the bin becomes small again.

Edge cases and gotchas

• Mutable keys: if fields used by equals() or hashCode() change after insertion, the object may become unreachable in the map.
• Cross-run values: the default identity hash is not meant to be stable across JVM runs, so do not store it as a business identifier.
• Hash collisions: same hash does not mean equal; Java still calls equals() after matching the bucket.
• Modern collections: the problem is not just HashMap; HashSet, LinkedHashMap, and many cache libraries rely on the same contract.

Memory hook: Think of a hash code as the shelf number in a library, and equals() as the book title check. If two identical books get different shelf numbers, the librarian never finds the second copy when searching for the first.

Real-World Example: In a checkout service, a team uses a custom OrderKey as the key in a HashMap that tracks idempotency, meaning "do not process the same payment twice." They override equals() to compare merchantId and orderId, but forget hashCode().

1. Two requests with the same logical order arrive during a retry storm.
2. One request is stored in the map; the retry creates a new OrderKey instance with the same field values.
3. The second lookup misses because the new object’s identity hash sends it to a different bucket.
4. The service thinks it is a new order, charges the customer again, and the support queue fills with duplicate-payment complaints.

What the team sees: logs like cache miss for orderId=12345, rising map size, and inconsistent behavior where the same request sometimes appears to be new and sometimes not, depending on whether the same object reference is reused. The root cause is not the map itself; it is a broken equality contract on the key class.

Follow-up & Tricky Questions:

Real follow-ups

• Why must equal objects have the same hash code? Because hash-based collections use the hash to choose a bucket before they call equals(). If equal objects hashed differently, the collection could search the wrong bucket and miss a valid match.
• What happens inside HashMap when collisions happen? Multiple keys land in the same bucket, and Java checks them with equals(). In Java 8+, a very crowded bucket may become a tree to keep lookups faster.
• Can two different objects share the same hash code? Yes. That is allowed and expected sometimes; it is called a collision. Java then uses equals() to tell them apart.
• Why is mutating a key dangerous? If the fields that affect equals() or hashCode() change after insertion, the object may be stored in the wrong bucket and become impossible to find.
• How do you implement hashCode() correctly? Use the same fields that define equality, keep it consistent with equals(), and prefer immutable key fields. Utility helpers like Objects.hash(...) are fine for many cases, though manual hashing can be faster in hot paths.

Tricky / gotcha questions

• If you override hashCode() but not equals(), is that enough? No. The collection will still use reference equality, so two logically same objects will not match unless they are the exact same instance.
• If two objects have the same hash code, are they equal? No. Same hash only means they went to the same bucket; Java still needs equals() to prove they really match.
• Does Object.hashCode() return the memory address? Not necessarily. The JVM only guarantees an identity-based value for that object during the run; the exact implementation is not part of the Java language contract.

Common Mistakes:

• Overriding equals() only: correction: always override hashCode() too when logical equality changes.
• Using mutable fields in keys: correction: prefer immutable fields or do not use the object as a hash key.
• Thinking same hash means equal: correction: collisions are normal; equals() is the final check.
• Using identity hash as a business ID: correction: it is only for in-memory identity, not durable data.

Memory Hook: Hash code is the apartment number; equals() is the face at the door. If two equal people are assigned different apartment numbers, the visitor never reaches the right door.

Cheat Sheet:

• Object.hashCode() is the default if you do nothing.
• Default hash is identity-based, not field-based.
• If equals() says two objects are equal, their hash codes must match.
• Breaking that rule hurts HashMap and HashSet lookups.
• Average hash-table access is O(1); bad collisions can push it toward O(n).
• Java 8+ may treeify very crowded buckets to improve worst-case behavior.

Practice Tasks:

• Write a class with equals() only, then prove a HashMap lookup can fail.
• Fix the class by adding a correct hashCode() and rerun the same test.
• Make one key field mutable, insert the object into a HashSet, change the field, and observe the lookup bug.