When presizing collections from an existing collection or stream, what subtle capacity pitfalls should you watch for?

## Why presizing from a source is subtle The goal of presizing is: allocate the backing storage once, big enough that no resize happens while you fill it. But the convenient idioms don't always achieve that, because of the **load factor** and how the JDK chooses capacity. ## Pitfall 1: `new HashMap<>(int)` with the raw element count ```java Map<K,V> m = new HashMap<>(n); // BUG if you expect n entries to fit ``` This sets *capacity* to (the next power of two ≥) `n`, but the map resizes at `capacity * 0.75`. So a map you intended to hold `n` entries resizes once it passes `~0.75 * n`. To hold `n` without resizing you need `capacity >= n / 0.75`: ```java Map<K,V> m = new HashMap<>((int)(n / 0.75f) + 1); ``` ## Pitfall 2: the `HashMap(Map)` copy constructor ```java Map<K,V> copy = new HashMap<>(source); ``` Its implementation sizes the new table based on `source.size()` and the **default load factor**. Historically (and depending on JDK version) this has been a source of an extra resize: in some versions it used `source.size()` directly against the threshold, so copying a nearly-full map could trigger a resize during construction. The safe, version-independent move is to size explicitly with `newHashMap` if you care. ## Pitfall 3: stream collectors can't be presized ```java Map<K,V> m = items.stream().collect(Collectors.toMap(K, V)); ``` `Collectors.toMap` (and `toList`, `toSet`, `groupingBy`) create the container and **grow it dynamically** — there is no hook to pass an initial capacity for the standard collectors. For large, known-size streams this means the usual cascade of resizes. If it matters, collect into a pre-sized container yourself (e.g. a `for` loop into a `HashMap.newHashMap(n)`), or use the supplier overload (`toMap(km, vm, merge, () -> HashMap.newHashMap(n))`). `Collectors.toCollection(() -> new ArrayList<>(n))` lets you presize a list. ## Pitfall 4: power-of-two rounding HashMap capacity is always a power of two. Asking for capacity 1000 yields 1024; asking for 1025 yields 2048. So memory comes in chunks, and tiny differences in your requested capacity can double the allocation. Don't over-think the exact number, but be aware that `+1` in the idiom can occasionally push you over a power-of-two boundary. ## Pitfall 5: capacity is a hint, not a cap Initial capacity never limits how many elements you can add. Undershoot and the collection simply resizes as needed — you lose the optimization but nothing breaks. Overshoot and you waste memory. So a wrong estimate is a performance issue, never a correctness one. ## The clean tools - **Java 19+:** `HashMap.newHashMap(n)`, `HashSet.newHashSet(n)`, `LinkedHashMap.newLinkedHashMap(n)` — these take the *expected number of elements* and do the load-factor maths for you. Prefer them. - **Guava:** `Maps.newHashMapWithExpectedSize(n)`, `Lists.newArrayListWithCapacity(n)`. - **ArrayList:** `new ArrayList<>(n)` or `new ArrayList<>(collection)` is already correct (no load factor). ## Summary The recurring theme: don't pass the raw element count as a HashMap *capacity* — account for the 0.75 load factor, prefer the `newHashMap`/Guava helpers, remember stream collectors don't presize, and treat capacity as a non-binding hint.