Immutability and Safe Publication

The cheapest concurrency strategy is to have nothing to synchronise. An object that cannot change after construction can be shared by any number of threads with no locks, no visibility concerns and no possibility of one thread observing another's half-finished update.

This is a pattern in the sense that matters — a named, reusable structural decision — and it is the one that removes the largest number of bugs per unit of effort. The mechanisms it replaces are covered under concurrency and thread safety; this topic is about the structure that makes most of them unnecessary.

What immutability actually guarantees

The guarantee is stronger than "no lost updates". A reader of a mutable object with several fields can observe a combination that never existed — the old currency with the new amount — because nothing makes multi-field updates atomic. Immutability removes that by making the whole object the unit of change: you replace it, you never edit it.

class Money {
  constructor(amountInCents, currency) {
    this.amountInCents = amountInCents;
    this.currency = currency;
    Object.freeze(this);
  }
  plus(other) {
    if (other.currency !== this.currency) throw new CurrencyMismatch();
    return new Money(this.amountInCents + other.amountInCents, this.currency);
  }
}

plus returns a new value. Two threads calling it on the same Money cannot interfere, because neither writes anything.

Deep immutability, not shallow

Freezing an object whose fields are mutable collections gives you a frozen shell around changeable contents — the same one-level-too-shallow error described under Prototype, with concurrency consequences.

class Order {
  constructor(id, lines) {
    this.id = id;
    this.lines = lines;          // still a mutable array
    Object.freeze(this);         // freezes the reference, not the array
  }
}

Any holder can call order.lines.push(...). Three rules make it real:

• Copy on the way in. The constructor takes a copy, so the caller's array is not your state.
• Freeze what you hold, recursively for nested structures.
• Copy or freeze on the way out, so a getter cannot hand out a mutable interior.

The cost is allocation, and it is almost always the right trade. Where it is not, a persistent data structure — one that shares unchanged parts between versions — gives immutability with sub-linear copying.

Safe publication: the subtle half

An immutable object is safe once other threads can see it correctly, and getting it there is a separate problem.

A reference published unsafely can be visible before the object's fields are. Another thread may see a non-null reference to an object whose fields still hold their default values, because the compiler and processor are permitted to reorder the write of the reference ahead of the writes of the fields. The object is correct; the publication was not.

Languages address this with a final-field guarantee: fields assigned in the constructor and never reassigned are guaranteed visible to any thread that sees the object, without synchronisation. This is why "immutable" in a concurrency discussion means specifically all fields final and assigned once, not merely "we do not call setters".

The escape that breaks it: letting this leave the constructor before it finishes — registering a listener, starting a thread, passing itself to a collaborator. Another thread then holds a reference to a partly-constructed object and the guarantee does not apply.

Copy-on-write

The practical middle ground when reads vastly outnumber writes: hold an immutable snapshot, and on a change build a new one and swap the reference atomically.

let routes = Object.freeze(new Map(initial));      // readers use this directly

function addRoute(path, handler) {
  const next = new Map(routes);
  next.set(path, handler);
  routes = Object.freeze(next);                     // one atomic reference swap
}

Readers need no synchronisation at all and never block. Writers pay a full copy, and a reader that captured the reference before the swap continues using the old snapshot — which is usually exactly what you want for configuration, routing tables and listener lists.

Where it fails: frequent writes. Copying a large structure per write is quadratic in a hot loop, and two concurrent writers can lose an update unless the swap uses a compare-and-set. Copy-on-write is for read-heavy, write-rare state.

Where mutability still belongs

Local, unshared state. Building a list inside a function and returning it frozen is fine and fast. The rule is about shared state.

Large structures with heavy churn. A simulation grid or an image buffer updated per frame should not allocate a copy per change; confine it to one owner instead.

Identity that must persist. An entity whose state changes over time — an order moving through its lifecycle — is naturally mutable, though the values it holds should be immutable, and its state transitions are better modelled with the State pattern than with field assignment.

Check your understanding

Common mistakes

Shallow freezing. A frozen object holding a mutable array is not immutable.

Getters returning interior collections. The encapsulation leaks and callers mutate your state.

Not copying constructor arguments. The caller keeps a reference and can change your state after construction.

Letting this escape the constructor. Other threads read uninitialised fields.

Copy-on-write under write pressure. Copying per write is quadratic in a loop.

A non-atomic copy-on-write swap. Two writers copy the same base and one update is lost.

Treating immutability as a concurrency-only concern. Most of the bugs it prevents are single-threaded aliasing failures.

Making an entity immutable. Things with identity and a lifecycle are naturally mutable; make the values they hold immutable instead.

Practice

Key takeaways

• Immutability removes the need to synchronise by removing the thing that changes — the cheapest concurrency strategy available.
• Its strongest guarantee is that no reader can observe a combination of fields that never existed.
• Deep, not shallow: copy constructor arguments, freeze nested structures, and never hand out interior collections.
• Safe publication is a separate problem. Fields assigned once in a constructor are guaranteed visible — unless this escapes before construction finishes.
• Never start a thread or register a callback from a constructor. Construct fully, then publish.
• Copy-on-write gives lock-free reads for read-heavy, write-rare state; it fails under write pressure and needs an atomic swap.
• Capture a snapshot once per unit of work. Re-reading a shared reference mid-request gives a coherent read each time and an incoherent request.
• Mutability still belongs in local unshared state, high-churn buffers, and entities with a lifecycle — whose values should still be immutable.

Further reading

• Brian Goetz and others, Java Concurrency in Practice (Addison-Wesley, 2006) — safe publication, final-field semantics and copy-on-write.
• Joshua Bloch, Effective Java, third edition (Addison-Wesley, 2018) — minimise mutability, and make defensive copies.
• Jeremy Manson, William Pugh and Sarita Adve, "The Java Memory Model" (POPL, 2005).
• Chris Okasaki, Purely Functional Data Structures (Cambridge University Press, 1998) — persistent structures with sub-linear copying.
• Eric Evans, Domain-Driven Design (Addison-Wesley, 2003) — value objects versus entities.