"A HashMap is fast not because collisions never happen. It is fast because it knows how to handle them efficiently."
In the previous articles, we built the foundation of HashMap thinking.
We understood:
- Why fast lookup is an important system behaviour.
- Why unique keys are valuable.
- How hashing converts keys into predictable locations.
Now let's go one level deeper.
A natural question appears:
"What happens when two different keys produce the same location?"
This is one of the most important concepts behind HashMaps.
Because in the real world, collisions are unavoidable.
Understanding how HashMaps handle them is what separates someone who knows how to use a HashMap from someone who understands how it works.
The Simple View Is Not the Complete Story
Earlier, we represented HashMap like this:
Key
↓
Hash Function
↓
Location
↓
Value
Enter fullscreen mode Exit fullscreen mode
This is a good mental model.
But internally, a HashMap does not have unlimited locations.
It has a fixed number of storage spaces.
These spaces are called:
Buckets
Think of buckets as containers where data can be placed.
Understanding Buckets
Imagine a warehouse.
The warehouse has multiple shelves.
Warehouse
Shelf 1
Shelf 2
Shelf 3
Shelf 4
Enter fullscreen mode Exit fullscreen mode
When a package arrives, a rule decides which shelf it belongs to.
Package ID
↓
Placement Rule
↓
Shelf Number
Enter fullscreen mode Exit fullscreen mode
A HashMap works similarly.
Instead of shelves, it has buckets.
HashMap
Bucket 0
Bucket 1
Bucket 2
Bucket 3
Bucket 4
Enter fullscreen mode Exit fullscreen mode
The hash function decides which bucket should receive a key-value pair.
Example:
User ID
↓
Hash Function
↓
Bucket Number
Enter fullscreen mode Exit fullscreen mode
The Perfect World Does Not Exist
Imagine we have four buckets.
Bucket 0
Bucket 1
Bucket 2
Bucket 3
Enter fullscreen mode Exit fullscreen mode
Now we store users.
User A
↓
Bucket 1
User B
↓
Bucket 3
User C
↓
Bucket 0
Enter fullscreen mode Exit fullscreen mode
Everything looks perfect.
Every user has a separate bucket.
But now another user arrives.
User D
↓
Bucket 1
Enter fullscreen mode Exit fullscreen mode
Wait.
Bucket 1 already contains User A.
What happens now?
This situation is called a:
Collision
What Is a Collision?
A collision happens when multiple keys produce the same bucket location.
Example:
User A
↓
Hash Function
↓
Bucket 1
User D
↓
Hash Function
↓
Bucket 1
Enter fullscreen mode Exit fullscreen mode
Two different users.
Same destination.
This is completely normal.
It does not mean the HashMap is broken.
A good HashMap design expects collisions.
Why Do Collisions Happen?
At first, beginners often think:
"If hashing creates locations, shouldn't every key get a different location?"
The problem is scale.
Imagine:
- Millions of possible keys.
- Only thousands of available buckets.
Many different keys will naturally map to the same bucket.
Think about a hotel.
A hotel has limited rooms.
Thousands of people may need accommodation.
Some people will eventually share the same room number on different days.
The limitation is not the people.
The limitation is the number of available rooms.
Similarly:
The limitation is not the keys.
The limitation is the number of buckets.
How Does a HashMap Handle Collisions?
There are different strategies.
The most common approach is:
Store multiple entries inside the same bucket.
Instead of thinking:
Bucket 1
↓
One Value
Enter fullscreen mode Exit fullscreen mode
Think:
Bucket 1
↓
Value A
↓
Value D
↓
Value X
Enter fullscreen mode Exit fullscreen mode
A bucket can contain multiple entries.
When retrieving data, the HashMap does a second-level search inside that bucket.
Two-Level Lookup
This is an important idea.
A HashMap lookup is not always:
Key
↓
Value
Enter fullscreen mode Exit fullscreen mode
Internally, it is closer to:
Key
↓
Hash Function
↓
Bucket
↓
Find Exact Key
↓
Value
Enter fullscreen mode Exit fullscreen mode
The hash function gets us close.
The exact key comparison confirms the correct entry.
Real-World Analogy
Imagine a company directory.
You search for:
Employee Name = Rahul
Enter fullscreen mode Exit fullscreen mode
The company first sends you to:
Department = Engineering
Enter fullscreen mode Exit fullscreen mode
But Engineering has many employees.
Now you search within that department.
Company Directory
↓
Engineering Department
↓
Find Exact Employee
↓
Rahul
Enter fullscreen mode Exit fullscreen mode
The first step reduces the search space.
The second step finds the exact match.
That is how collision handling works.
Why Good Hash Functions Matter
A good hash function tries to distribute keys evenly.
Imagine this situation:
Bucket 0
User A
User B
User C
User D
User E
Bucket 1
Empty
Bucket 2
Empty
Enter fullscreen mode Exit fullscreen mode
One bucket has too much data.
Other buckets remain unused.
This creates slower lookups.
A better distribution looks like:
Bucket 0
User A
Bucket 1
User B
Bucket 2
User C
Bucket 3
User D
Enter fullscreen mode Exit fullscreen mode
The goal is balance.
Spread information evenly.
Real-World Impact
Consider a session management system.
Millions of users are logged in.
Each session is stored using:
Session ID
↓
Session Information
Enter fullscreen mode Exit fullscreen mode
If hashing distributes sessions properly:
Session IDs
↓
Multiple Buckets
↓
Fast Retrieval
Enter fullscreen mode Exit fullscreen mode
The system remains responsive.
If distribution is poor:
Many Sessions
↓
One Bucket
↓
More Searching
↓
Slower Requests
Enter fullscreen mode Exit fullscreen mode
The application performance suffers.
HashMap Performance Depends on Design
People often say:
"HashMap lookup is O(1)."
This is generally true under good conditions.
But the complete story is:
Fast lookup depends on:
- Good hash function.
- Good key selection.
- Reasonable bucket distribution.
- Efficient collision handling.
A HashMap is not automatically fast.
Its performance depends on how well these pieces work together.
Weak Thinking vs Strong Thinking
Weak Thinking
HashMaps are O(1).
They are always instantly fast.
Enter fullscreen mode Exit fullscreen mode
Strong Thinking
HashMaps are designed for fast lookup.
Their performance depends on good hashing,
balanced distribution and collision handling.
Enter fullscreen mode Exit fullscreen mode
Weak Thinking
Collision means the HashMap failed.
Enter fullscreen mode Exit fullscreen mode
Strong Thinking
Collisions are expected.
A good HashMap is designed to handle them efficiently.
Enter fullscreen mode Exit fullscreen mode
Common Beginner Mistakes
Mistake 1 — Believing collisions should never happen
Collisions are a natural consequence of limited storage locations.
Mistake 2 — Thinking the hash function directly stores data
The hash function only helps determine the bucket.
The actual key-value pair is stored separately.
Mistake 3 — Memorising O(1) without understanding conditions
Complexity depends on assumptions.
Real systems need good design decisions to maintain performance.
Mistake 4 — Ignoring key quality
Poor keys can create poor distribution.
Good system design begins with choosing meaningful identifiers.
Interview Perspective
A common interview follow-up after explaining HashMaps is:
"What happens if two keys have the same hash?"
A weak answer:
"The HashMap breaks."
A stronger answer:
"Different keys can map to the same bucket. The HashMap handles this collision by storing multiple entries in the bucket and comparing the actual keys to find the correct value."
This shows that you understand the internal behaviour.
The Most Important Insight
The power of a HashMap does not come from avoiding collisions.
It comes from reducing unnecessary searching and handling collisions efficiently when they occur.
A good engineer understands both parts:
- How to reach the right area quickly.
- How to find the exact information once there.
One-Line Takeaway
A HashMap is fast because hashing gets you close quickly, and collision handling helps you find the exact answer reliably.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.