Immutability has real costs - what are they, and how do you mitigate them when state must change frequently?

## Why immutability costs anything An immutable object's state is fixed at construction. So a logical 'update' - increment a counter, add an element, change a field - cannot edit the existing object; it must **produce a new object** carrying the changed value. Three concrete costs follow. ### 1. Object churn / allocation pressure If you perform N updates, you allocate N objects (the intermediate versions are garbage). Allocation in the JVM is cheap per object (bump-pointer in the young generation), but it's not free, and N can be large. The textbook case: ``` String s = ""; for (String part : parts) s = s + part; // each += builds a NEW String ``` Each `+` copies all characters so far plus the new ones into a fresh `String`, giving **O(n^2)** total character copies and n-1 throwaway Strings. The same shape appears with naive `BigInteger`/`BigDecimal` loops or rebuilding an immutable list element-by-element. ### 2. Copy-on-modify overhead When an immutable object **contains** a mutable component (array, collection), producing the next version often **copies the whole component** to keep the old version intact. `List.copyOf` / building a new `ArrayList` to make an unmodifiable list is O(size) per change. So a sequence of single-element 'adds' to an immutable list copies the entire backing array each time. ### 3. GC impact All those intermediate objects become garbage that the collector must trace and reclaim. With many short-lived objects, **minor (young-gen) GCs** run more often. Generational collectors are tuned for exactly this 'most objects die young' pattern, so it's usually cheap - but in latency-sensitive or extremely hot paths it can add pauses and CPU. ## Mitigations ### A. Mutable companion, immutable result Use a purpose-built **mutable builder** for the hot loop and convert to an immutable value once: - `StringBuilder` -> `toString()` instead of `+=`. - A local `ArrayList` you fill, then `List.copyOf(list)` at the end. - A `record` or immutable value assembled once from accumulated locals. The mutation is **confined** (thread-local, not shared), so you keep the safety benefits at the boundary while paying allocation only once. ### B. Persistent / structural-sharing structures **Persistent data structures** create a new logical version that **shares** most of its internal nodes with the previous version, copying only the path that changed (O(log n) instead of O(n)). Examples: many functional/immutable collection libraries, and Java's own copy-on-write is the opposite extreme (full copy). Structural sharing makes 'immutable but frequently updated' affordable. ### C. Batch the changes Instead of updating one field at a time (one allocation each), compute all changes and build the new object **once**. A `with`-style API or builder that takes several new values amortizes allocation. ### D. Trust the runtime where appropriate - **Generational GC**: short-lived garbage is collected cheaply in the young generation; don't pre-optimize against it without evidence. - **Escape analysis**: the JIT can detect objects that never escape a method and **scalar-replace** them (no heap allocation at all) or stack-allocate, erasing the cost in some hot, inlined paths. Measure (allocation profiling, GC logs, JFR) before trading away immutability. ## The judgment call The right rule is **immutable by default, mutable by exception**. Immutability buys thread safety, safe sharing, valid keys, and simpler reasoning - usually worth a little allocation. You introduce a mutable companion only in **localized, profiled hot spots** where churn measurably hurts, and you keep that mutability **confined** so the rest of the system still enjoys immutability's guarantees. This is precisely the design behind `String` (immutable, shared, safe) living next to `StringBuilder` (mutable, fast, local).