---

Junior Level

Immutability has both pros and cons for performance.

Cons (costs)

• Each “modification” creates a new object — this consumes memory
• For large objects, copying can be slow

Pros (optimizations)

• No locks needed (synchronized) — faster in multi-threading
• Objects can be cached and reused
• Fewer bugs — less debugging time

Simple rule

• Single thread, frequent edits — mutability is faster (StringBuilder)
• Multi-thread, read-heavy — immutability is faster (no locks)

---

Middle Level

Negative impact

Allocation and copying — each modification = new object + data copying.

• For large objects — $O(n)$ operation in time and memory
• Fills up Eden space (Young Generation)
• More frequent Minor GC cycles

Positive impact

Lock-free algorithms — threads read without locks. In multi-threaded systems, absence of monitor contention gives a huge throughput boost.

JIT optimizations — the compiler knows final fields won’t change:

• Aggressive Inlining
• Constant Folding — computation at compile time
• Caching in CPU registers

Comparison

Scenario	Mutability	Immutability
Single thread, frequent edits	Faster	Slower
Multi-thread, reading	Slower (locks)	Faster (lock-free)
Map keys	Dangerous	Ideal

// In practice: object allocation ~10ns, copying 1000-element array ~100ns. // StringBuilder vs String concat: over 10000 iterations, difference is 100-1000x.

---

Senior Level

Write Barriers and GC

In generational garbage collectors (G1, ZGC), modifying an old object with a reference to a new one requires a Write Barrier. Immutable objects are created once and never change — such checks are minimized.

Young Generation Efficiency

Modern JVMs allocate objects in Young Gen via Bump-the-pointer — this is simply a pointer increment, extremely fast. Short-lived objects are cleaned up for free during Minor GC.

Strategic choice

Immutability is an investment in scalability:

• On a single core with intensive changes to one object, mutation is usually faster, as it avoids allocation and copying.
• On a cluster / in a multi-threaded service, immutability wins due to absence of locks and predictable memory

Practical rule

• Use mutable buffers (StringBuilder, ArrayList) for building data
• Use immutable objects for storing and transferring data

Summary for Senior

• Immutability — a strategic investment in scalability
• At the single CPU level mutation is faster, at the cluster level — immutability wins
• JIT uses final for aggressive optimizations
• GC benefits from absence of Write Barriers
• Combine: mutable for building, immutable for storing

---

Interview Cheat Sheet

Must know:

• Cons: new object allocation, O(n) copying, GC pressure (Eden space)
• Pros: lock-free in multi-threading, JIT optimizations (inlining, constant folding), caching
• StringBuilder vs String concat: over 10000 iterations, difference is 100-1000x
• Write Barriers — immutable objects eliminate such overhead
• Young Gen: Bump-the-pointer allocation — fast, Minor GC cleans for free
• Strategy: mutable buffers for building, immutable objects for storing

Frequent follow-up questions:

• When is mutability faster? — Single thread, frequent edits to one object
• When is immutability faster? — Multi-thread, reading (no locks)
• What is Write Barrier? — Check on Old Generation modification; immutable objects don’t need it
• Does JIT use final? — Yes: aggressive inlining, constant folding, hoisting from loops

Red flags (do NOT say):

• “Immutability is always slower” — in a multi-threaded environment without locks it’s faster
• “StringBuilder is not needed” — for concatenation in a loop the difference is 100-1000x
• “GC can’t handle short-lived objects” — Minor GC cleans them for free
• “Immutability is better on a single core” — mutation is usually faster single-threaded

Related topics:

• [[2. What advantages do immutable objects provide]]
• [[5. What are the consequences of String immutability]]
• [[22. What are the advantages of immutable objects for caching]]
• [[25. Are there disadvantages to immutable objects]]