# Moms are Hashmapping Geniuses - Part 2: Rehashing, Load Factor and an Ever Expanding Kitchen ## A Continuation of the Journey Now that I had a pretty solid mental model of how `HashMap` works — and how my mom had been resolving collisions in God Mode all along — something else started to bug me. Sure, collisions were clever. Linear probing, chaining, jumping around — we had it all under control. But what about **capacity**? Her kitchen never looked full. Never felt cramped. No packet was left out. No drawer was overloaded. No last-minute reshuffling just to make room. Even as new items kept coming in, week after week — everything still had a place. I couldn’t help but ask: > “How does this system never get overwhelmed?” Because in my head, the HashMap should’ve collapsed by now. That’s when I realized: Mom wasn’t just solving problems. She was **anticipating them**. Scaling silently in the background — without any of us noticing. She wasn’t just **hashing**. She was **rehashing** — long before I even knew the term. And like any curious dev at 2 a.m., I opened up my search engine and typed just two words: > `HashMap scale?` --- ## What is Load Factor? Remember how my mom’s kitchen never felt crowded? Even as new packets showed up — somehow, everything still fit. It wasn’t just about drawer space. It was about **when** she decided it was time to expand. In the world of `HashMap`, that moment is driven by a little number called the **Load Factor**. ### Load Factor Defined (Tech Speak) ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1744120007533/5403df36-dfa3-4a65-ac51-28b0be1cac04.png align="center") Load Factor is a threshold — a ratio that tells the `HashMap` when it’s getting too full and might need to **grow**. It's calculated as: ```java Load Factor = Number of Stored Entries / Total Buckets ``` If this ratio crosses a certain value — typically `0.75` in Java’s default `HashMap` — the structure resizes itself (we'll get there in a bit). ### 🍽 Kitchen Analogy Imagine your kitchen has **16 drawers**. And mom’s personal rule is: "If more than **12** of them are used, it's time to expand." That 12/16 = `0.75` — the **Load Factor**. It's like mom’s internal radar. She doesn’t wait until every drawer bursts open. She scales **before** chaos hits — proactively, not reactively. So the Load Factor in a HashMap is that same radar. A quiet little signal saying: > “Hey, things are getting tight around here — time to make room.” ### Why Not Just Wait Till It’s Full? Because performance matters. As the map gets more crowded, the chance of **collisions** increases. More collisions mean more fallback strategies — which slows things down. So to **preserve speed**, HashMap watches its load factor and expands **before** performance degrades. Your mom? She does the same. When drawers start to feel *just a little* too full — she’s already upgrading to a bigger shelf. ## What is Rehashing? When the **Load Factor** crosses its threshold, the `HashMap` doesn’t panic. It doesn’t start throwing keys out the window. Instead, it calmly says: > “Okay. Time to grow. Time to rehash.” ### What Happens During Rehashing? ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1744120027054/2b955528-d867-49fb-9aba-ce1dde30cf23.png align="center") Rehashing is the process where the internal **array (bucket table)** of the HashMap is expanded — usually **doubled in size** — and **all existing entries are re-inserted** into this new, larger table. But here’s the twist: > The *position* of each key may **change** in the new table —> because it’s recalculated using the new size. That’s why it’s called **re-hashing** — you don’t just copy things over, you re-calculate their place from scratch using the new capacity. ### 🍽 Kitchen Analogy Let’s say you had 16 drawers in the kitchen. And now, thanks to new groceries and rising complexity, your mom decides to expand. She buys a **new shelf** with **32 drawers**. She doesn’t just move each item randomly. She *rethinks* — “Hmm, now with more space, where does each item make the most sense?” So she takes every packet — sugar, salt, coffee beans —and puts them into the **new drawer it belongs to**, based on the **new setup**. The older drawer numbers? Obsolete. There’s a whole new logic in town. ### 🧮 Rehashing in Steps Here’s what really goes down when a rehash is triggered inside a `HashMap`: 1. **Load Factor Check**: Every time a new entry is added, the HashMap evaluates its current load factor — calculated as `number of entries / current bucket size`. 2. **Threshold Breach**: If the load factor crosses the defined threshold (usually `0.75` in Java), it knows it’s time to grow — before performance takes a hit. 3. **New Bucket Array Creation**: A brand-new bucket array is created, typically with **double the size** of the original. 4. **Re-Insertion Begins**: The HashMap doesn’t just copy data blindly. Instead, it **iterates over each entry** in the old array, and for each key-value pair, it: * Recomputes the new hash using the updated capacity. * Inserts the entry into the correct new bucket using the `insert()` method. > The rehashing process is not just a resize — it's a full **redistribution** of the existing data. ### ⚠️ Wait — Does Rehashing Hurt Performance? Yes — but only briefly. Rehashing isn’t something that happens in the background while your application continues running. It is **triggered synchronously** when a new key-value pair is inserted **and** the load factor is breached. That means: **the insertion that crosses the threshold is the one that pays the price**. It takes the hit — does the heavy lifting of rehashing — and only then completes. So while 99.9% of operations in a HashMap are blazing fast O(1), a single insert during a resize might momentarily feel like O(n). This is why many high-performance applications either: * Pre-define the initial capacity to avoid frequent rehashes. * Use alternative data structures if predictable latency is mission-critical. So yes, performance *can* dip for that one insert — but it's a small price for keeping the rest of your kitchen clean, efficient, and lightning fast. --- ## Visualizing Rehashing: Before and After Let’s make this concrete. Suppose we had a small `HashMap` with **capacity = 5** and inserted these keys:**17, 67, 32, 43** They’d be placed like this: ### 🧺 Old HashMap (Size = 5) | **Bucket** | **Entries** | | --- | --- | | 0 | — | | 1 | — | | 2 | 17 → 67 → 32 | | 3 | 43 | | 4 | — | Now, we cross the load factor threshold → time to **rehash** and **double the capacity to 10**. ### 🧺 New HashMap (Size = 10) | **Bucket** | **Entries** | | --- | --- | | 0 | — | | 1 | — | | 2 | 32 | | 3 | — | | 4 | — | | 5 | — | | 6 | 43 | | 7 | 17 | | 8 | — | | 9 | 67 | Just like that, everything now lands in its **own clean slot**. No collisions. No chains. Lookup speed back to lightning fast. --- ## Scaling Done Right And here’s the best part: Just like my mom never lets her kitchen overflow, HashMap never waits till it's too late. It monitors the **Load Factor** quietly in the background. And the moment it senses clutter on the horizon — it doesn’t panic. It grows. It reorganizes. It comes back stronger. > HashMap doesn’t just *handle* growth. > It’s **designed** for it. And now, every time I resize a data structure or bump up a cache… I think back to the kitchen — and silently thank the moms who rehash in real life without ever calling it that. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1744120835957/a36625c9-6daa-4bcd-8132-b9a8fc3f1ab4.png align="center") --- ## **Next Up? We Build One Ourselves.** We've talked drawers. We've talked collisions. We've talked expansion like my mom upgrades her kitchen. But what if we tried building a HashMap from scratch — one drawer, one key, one collision at a time? In the next blog, I’ll try exactly that. No `java.util.*`, no magic — just plain code, bugs, and a lot of console prints. **Because moms may be hashing geniuses… but I’m not.** [Click here for *“Moms are Hashmapping Geniuses, I Am Not — Let’s Code a HashMap in Java.”*](https://theharshtech.hashnode.dev/moms-are-hashmapping-geniuses-i-am-not-lets-code-a-hashmap-in-java)