Load Factor and Initial Capacity.

Hook: Interviewers love this question because it tells them whether you know that a HashMap is not magic — it is just a table that gets fuller, then grows.

Question: What do load factor and initial capacity mean in Java collections, especially HashMap?

Answer: The initial capacity is the number of buckets a map starts with, and the load factor is the fullness limit that decides when the map should grow. In HashMap, the default load factor is 0.75f and the default starting capacity is effectively 16 once the table is created. When the number of stored entries passes capacity × loadFactor, Java resizes the table, which is why pre-sizing can improve performance.

Interview-Ready Answer: I think of initial capacity as the starting number of buckets, and load factor as the fill limit before resizing. In Java's HashMap, the default load factor is 0.75 and the default capacity is 16, so the resize threshold is 12. If I know roughly how many entries I will store, I pre-size the map to avoid costly resize and rehash work.

What these two numbers really mean

Detailed Explanation: A HashMap stores entries in an internal array called the buckets array. Each bucket can hold one or more entries that hash to the same place. The initial capacity is the starting size of that array, while the load factor is the fraction of the array that can be used before Java decides to resize it.

1. When you create a HashMap, Java remembers the requested capacity and load factor.
2. In modern Java, the table is usually allocated lazily, meaning the actual array is often created on the first put, not immediately at construction time.
3. Java computes a threshold: capacity × loadFactor.
4. As you add entries, once size > threshold, the map grows, usually by doubling the capacity.
5. During resize, all existing entries are redistributed into the new table. This is the expensive part.

Example: with capacity 16 and load factor 0.75, the threshold is 12. The 13th entry triggers a resize to a larger table, usually 32.

Why Java uses 0.75 by default

A load factor around 0.75 is a practical balance. If the table is too empty, you waste memory. If it is too full, collisions increase, and each get or put has to inspect more entries in the same bucket.

When to use pre-sizing: If you know the approximate number of entries, choose an initial capacity large enough so the map will not resize during normal use. A simple rule is: neededCapacity = ceil(expectedEntries / loadFactor), then round up to the next power of two because HashMap uses power-of-two sizing internally.

For example, if you expect 100 entries and use 0.75, you need at least 134 slots before rounding. The next power of two is 256, which gives a threshold of 192. That means 100 inserts fit comfortably without a resize.

What happens under the hood

1. A key's hash is mixed and mapped to a bucket index.
2. The entry is placed into that bucket.
3. If many keys land in the same bucket, Java stores them in a small chain; in Java 8+, long chains may become tree bins for better performance.
4. When the map crosses its threshold, Java allocates a bigger table and moves entries over.
5. This resize is usually an O(n) operation, but because it happens infrequently, normal operations stay amortized O(1) on average.

Important version note

In Java 8 and later, HashMap improved worst-case collision handling by treeifying long chains when the table is large enough. The key idea of load factor and initial capacity did not change, but the collision strategy became more robust.

Memory hook: Think of a parking lot: initial capacity is the number of spots, and load factor is the rule that says, 'when the lot is about this full, open a new section before traffic gets jammed.'

Real-World Story: Imagine a checkout service that builds a HashMap of cart items for every request. Most carts have about 20 to 40 items, but on sale day some have 200. If the team leaves the map at default size, the hot path keeps resizing over and over for large carts, which adds CPU work and can raise p99 latency.

What goes wrong in a bad release: an engineer sets the initial capacity to the expected item count, but forgets that the threshold is lower than the capacity because of the load factor. The map still resizes earlier than expected, so profiling shows HashMap.resize near the top of the CPU flame graph. Users feel it as slower checkout, and logs may only show general request slowdown, not a clear error.

The fix is to estimate real entry counts, divide by the chosen load factor, and round up properly. That way the map stays stable during the request and avoids expensive rehashing work.

Follow-up & Tricky Questions:

• What is the default load factor in HashMap? It is 0.75f. That is the standard balance Java chose between memory usage and collision cost.
• What is the default initial capacity? The usual default starting capacity is 16 once the table is created. In modern Java, allocation is often lazy, but the default size behavior is still based on 16.
• How do you choose an initial capacity for 1,000 entries? Divide by the load factor: 1000 / 0.75 gives about 1334, then round up to a power of two. That helps avoid resize spikes.
• Does a higher load factor always make a map faster? No. It uses less memory and resizes less often, but buckets get fuller, so lookups can slow down because there are more collisions.
• Does initial capacity guarantee no resizing? Only if it is large enough for the expected size and load factor. If you underestimate, the map still resizes when the threshold is crossed.
• Tricky: if I pass 100 as initial capacity, does the table become exactly 100 buckets? No. HashMap rounds to a power of two, so the actual internal size may become 128 or another power of two depending on the implementation rules.
• Tricky: is resize triggered when size equals threshold? Not exactly; it happens when the size becomes greater than the threshold after insertion. That is why a threshold of 12 means the 13th element causes growth.
• Tricky: is the load factor a percentage of used memory? No. It is a ratio of entries to bucket count, not a heap-memory percentage.

Common Mistakes:

• Confusing capacity with threshold. Capacity is the bucket count; threshold is the point where resizing starts. The correction is to remember the formula: threshold = capacity × loadFactor.
• Setting capacity equal to expected entries. That can still resize early because the threshold is smaller than capacity. The correction is to divide expected entries by the load factor first.
• Picking an extreme load factor without a reason. Very low values waste memory, and very high values increase collisions. The correction is to use the default 0.75 unless you have measured evidence to tune it.
• Forgetting that Java rounds capacity. Passing 50 does not mean the internal table is 50. The correction is to expect power-of-two sizing and plan with that in mind.

Memory Hook: Spots vs fullness rule: initial capacity is how many parking spots you start with, and load factor is how full the lot can get before you open another section.

Cheat Sheet:

• Load factor = how full before resize.
• Initial capacity = starting bucket count hint.
• Default HashMap load factor = 0.75f.
• Default HashMap starting capacity = 16.
• Resize threshold = capacity × loadFactor.
• For known sizes, use ceil(expected / loadFactor) and round up.

Practice Tasks:

• Write a helper that computes the recommended initial capacity for 10, 100, and 10,000 expected entries.
• Try the same insert workload with default sizing versus pre-sizing and use a profiler or simple timing to see the difference.
• Test invalid values such as 0 or a negative load factor and confirm Java throws IllegalArgumentException.