Why HashMap Uses a Load Factor of 0.75: Load Factor, Collision Resolution, and the Poisson Distribution

HashMap is built on a hash table where each key‑value pair is placed according to a hash function; the load factor measures how full the table is and directly influences when the table is resized.

The load factor is defined as number of entries / table length . A larger factor improves space utilization but increases the chance of collisions, while a smaller factor reduces collisions at the expense of wasted space and more frequent rehashing.

Collision‑resolution methods covered include:

Open addressing (linear probing, quadratic probing, pseudo‑random probing) – each with its own step‑size strategy and drawbacks such as clustering and deletion complexity.

Rehashing – using a secondary hash function to find an alternative slot, which reduces clustering but adds computation.

Separate overflow area – storing colliding entries in an auxiliary array, which requires scanning the overflow area during look‑up.

Chaining (linked‑list or red‑black tree) – the approach actually used by Java's HashMap, combining an array with per‑bucket linked lists (or trees) to handle collisions efficiently.

Java's HashMap defaults to an initial capacity of 16 and a load factor of 0.75; when size >= capacity * loadFactor (i.e., 12 entries for the default capacity), the table is resized and all entries are rehashed.

The choice of 0.75 is grounded in statistical analysis: assuming random hash codes, the distribution of bucket chain lengths follows a Poisson distribution with λ≈0.5. Under this model, the probability of a bucket containing more than 8 entries is less than 1 in ten million, making 0.75 a practical compromise between memory usage and lookup performance.

Alternative factors such as 0.6 or 0.8 would shift this balance; a lower factor would waste memory and trigger more frequent resizes, while a higher factor would increase cache misses and degrade lookup speed, especially for hash tables that rely on open addressing.

In summary, the default load factor of 0.75 reflects a trade‑off derived from Poisson‑distribution expectations, providing acceptable collision rates while keeping memory overhead reasonable for typical Java applications.

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

public int hashCode() {
    int h = 0;
    Iterator
> i = entrySet().iterator();
    while (i.hasNext())
        h += i.next().hashCode();
    return h;
}

Hi = (H(key) + d_i) MOD m  // open addressing formula

Hi = RHi(key)  // rehashing formula