Load Factor, Fail-Fast and Fail-Safe

#Introduction

These four concepts are high-frequency HashMap interview topics:

1. Load factor
2. Why HashMap isn't thread-safe
3. Fail-fast iterators
4. Fail-safe (and weakly consistent) iterators

The key is to understand how they connect rather than memorizing definitions.

#1. Load Factor

Load factor tells HashMap how full the table is allowed to become before resizing.

Default:

loadFactor = 0.75f;

The basic formula:

threshold = capacity × load factor

For example:

capacity    = 16
load factor = 0.75

threshold   = 16 × 0.75
            = 12

When the number of entries crosses the resize threshold, HashMap grows its internal table.

Why 0.75?

It's a trade-off between memory and performance.

0.75 is the default practical compromise.

Interview Trap

#2. Why HashMap Isn't Thread-Safe

HashMap is not designed for concurrent modification by multiple threads.

Map<String, Integer> map = new HashMap<>();

Two threads execute:

map.put("A", 10);
map.put("B", 20);

Without proper synchronization, concurrent operations can interfere with each other.

Check-then-act race

Compound operations are clearly unsafe:

if (!map.containsKey(key)) {
    map.put(key, value);
}

Read-modify-write: the counter

map.put("count", map.get("count") + 1);

With an initial value of 10:

The fix

For concurrent use:

ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();

map.merge("count", 1, Integer::sum);

#3. Fail-Fast Iterator

A fail-fast iterator detects certain structural modifications to a collection while you're iterating and may throw ConcurrentModificationException.

Map<Integer, String> map = new HashMap<>();

map.put(1, "A");
map.put(2, "B");

for (Integer key : map.keySet()) {
    map.put(3, "C");
}

ConcurrentModificationException

Why?

HashMap maintains an internal modification count, commonly referred to as modCount. The iterator maintains an expected modification count.

Fail-Fast ≠ Thread-Safe

A very common interview trap. Fail-fast behaviour does not make HashMap thread-safe — it is primarily a mechanism for detecting problematic modification during iteration.

#4. Fail-Safe Iterator

"Fail-safe iterator" is a commonly used interview term, but it is not the precise JDK terminology. Interviewers typically use it to describe an iterator that can continue when the underlying collection is modified, often because iteration works against a snapshot or because the collection has special concurrent semantics.

CopyOnWriteArrayList

List<Integer> list = new CopyOnWriteArrayList<>();

list.add(1);
list.add(2);

for (Integer i : list) {
    list.add(3);
}

The iterator works against a snapshot-like array state. It doesn't throw ConcurrentModificationException merely because the list is modified.

#5. ConcurrentHashMap Is Different

ConcurrentHashMap<Integer, String> map = new ConcurrentHashMap<>();

The iterator is technically weakly consistent — not "fail-safe" in the JDK's terminology.

for (Integer key : map.keySet()) {
    map.put(3, "C");
}

It doesn't behave like HashMap's fail-fast iterator, but it also doesn't provide a guaranteed snapshot. Depending on timing, it may or may not see some concurrent changes.

#6. Fail-Fast vs Weakly Consistent vs Snapshot

This distinction is extremely useful in interviews.

#7. One Very Important Correction

You may hear: "HashMap has a fail-fast iterator and ConcurrentHashMap has a fail-safe iterator." That's acceptable as basic interview terminology, but for a strong Java interview answer say:

That demonstrates deeper knowledge.