HashMap Capacity and Load Factor

Direct Answer

Initial capacity is the table size used when HashMap allocates its buckets; a default-constructed map allocates lazily, with a default target capacity of 16. Load factor controls the resize threshold; the default is 0.75. If you know the expected mappings, size the map to avoid repeated growth, but remember capacities are normalized internally and exact allocation is an implementation detail.

Code Example

When you know how many entries are coming, pre-sizing skips the repeated resize-and-redistribution storms a default map would suffer.

import java.util.*;

public class CapacityDemo {
    public static void main(String[] args) {
        // Default: capacity 16, load factor 0.75 -> resizes at 12 entries
        Map<String, Integer> def = new HashMap<>();

        // Expecting 1000 entries? Pre-size to avoid repeated resizing:
        int expected = 1000;
        int cap = (int) (expected / 0.75f) + 1;     // ~1334
        Map<String, Integer> sized = new HashMap<>(cap);
        for (int i = 0; i < expected; i++) sized.put("k" + i, i);
        // No resize storms during the loop.

        // Custom load factor (rarely needed): more memory, fewer collisions
        Map<String, Integer> tight = new HashMap<>(64, 0.5f);
    }
}

Note n / 0.75 + 1, not n — capacity equal to n would still trip the 0.75 threshold and resize.

Common Mistakes & Pitfalls

• Setting capacity to exactly n. The 0.75 factor still triggers a resize at 0.75 x n; estimate room for n mappings at the chosen load factor.
• Forgetting power-of-two rounding. Allocated table capacity is normalized to a power of two by the current implementation.
• Tuning the load factor blindly. 0.75 is a good default; change it only with a measured reason.
• Ignoring resize cost. Each resize is O(n) and redistributes existing entries — wasteful in tight loops.