Immutable Objects for Safety

Three ingredients — remove one and the bug is gone

A data race needs shared and mutable and uncoordinated. That gives you three ways out, and they are not equally priced:

• Remove shared — give each thread its own copy or confine the object to one thread. Works, but you often need the sharing.
• Remove uncoordinated — add a lock (Locks, Mutex, Semaphore) or a read-write lock (Read-Write locks). Correct, but now you own a lock: contention, blocked readers, and a chance to deadlock (Deadlock, race conditions, starvation).
• Remove mutable — make the object immutable. No lock to acquire, no lock to forget, nothing to contend on, and readers never block each other. This is the cheapest of the three whenever it fits.

The torn read: a state that never legally existed

This is the bug the prototype dramatises. A writer updates two fields of a shared object. In the source it looks like a single change; at runtime it is two separate writes with a gap in between. A reader that arrives in that gap sees the new x and the old y — an object that is internally inconsistent, a combination the program never intended to produce. That's a torn read (also called an inconsistent or half-updated read):

// MUTABLE and shared — the writer's "one change" is really two writes.
class Point {
    int x = 1, y = 2;               // invariant we care about: x == y
}

Point p = new Point();              // shared by every thread

// writer thread
p.x = 9;                            // ← step 1
                                    // ← a reader arriving HERE sees x:9, y:2
p.y = 9;                            // ← step 2

// reader thread
System.out.println(p.x + "," + p.y); // may print 9,2 — a state that
                                     // never legally existed

Notice what makes this so nasty: nothing crashed, no exception was thrown, and the reader's own code is flawless. It simply observed a moment that the writer never meant to expose. Bugs like this appear once in ten thousand runs and are almost impossible to reproduce on demand.

Change by copy — the old object stays valid

An immutable object cannot be half-updated, because it is never updated at all. A "change" is a method like withX(9) that builds and returns a brand-new object and leaves the original exactly as it was. That's the boarding pass being reprinted. Crucially, a thread still holding the old reference is not broken or stale-in-a-dangerous-way — it holds a consistent snapshot of an earlier moment, which is almost always fine and sometimes exactly what you want (a report, a request being served, a frame being rendered).

// A record is immutable: fields are final, there are no setters.
public record Point(int x, int y) {

    // "mutators" are really factories — the original is never touched.
    public Point withX(int newX) { return new Point(newX, y); }
    public Point moveTo(int nx, int ny) { return new Point(nx, ny); }
}

Point v1 = new Point(1, 2);
Point v2 = v1.moveTo(9, 9);   // v2 is a NEW object, fully formed
// v1 is STILL (1, 2) for anyone holding it — a valid older snapshot.
// There is no moment in which any Point exists as (9, 2).

Safe publication for free

There is a second, subtler win. Normally, handing a freshly built object to another thread is risky: the other thread can see the reference before it sees the fields the constructor wrote — the classic broken double-checked lock in Thread-safe Singleton. Java closes that hole for immutable objects: if a field is final, any thread that sees the object at all is guaranteed to see that field correctly initialised, with no volatile and no lock. That guarantee is written into the language spec (the final field semantics of the Java Memory Model). Immutable objects are therefore safe to publish by any means at all — a plain field, a HashMap, a queue, a callback.

The atomic swap: keep the mutable part to one reference

"Nothing ever changes" is fine for a Money or a Point, but real programs do change — configuration reloads, prices update, routing tables shift. The idiom that makes immutability practical is to shrink the mutable part down to a single reference, and make every change one pointer swap. The data is immutable; only the pointer to the current version moves. Because swapping a reference is a single atomic operation, every reader sees either the whole old version or the whole new version — never a mixture. That is exactly the current ▼ arrow swinging from v1 to v2 in the prototype.

public record Config(String host, int port, int timeoutMs) {}

// The ONLY mutable thing in the whole design: one reference.
static final AtomicReference<Config> CURRENT =
        new AtomicReference<>(new Config("a.example", 80, 500));

// Readers — thousands of threads, no lock, never blocked.
Config c = CURRENT.get();        // one read gets a consistent whole
use(c.host(), c.port());         // c can NEVER change under us

// Writer — build the new version, then swap in one step.
Config next = new Config("b.example", 443, 800);
CURRENT.set(next);               // all-or-nothing for every reader

Note what readers get here: CURRENT.get() once, into a local variable, and from then on the object is frozen for as long as they need it. A reader that started before the swap simply finishes its work against the older config — consistently. This is the same shape as copy-on-write collections (CopyOnWriteArrayList), where a mutation copies the whole array and swaps the reference: reads are free and lock-free, writes are expensive.

What it costs

• Allocation and GC pressure — every change makes a new object. For small value objects in a modern runtime this is close to free; in a hot loop that rebuilds a large object millions of times, it is not.
• Copying big structures — replacing one entry in a 100 000-element immutable map by copying the whole map is O(n) per write. Persistent (structural-sharing) data structures solve this by sharing the untouched parts between versions, giving O(log n) "copies" — that's what Clojure's collections, Scala's Vector, and libraries like Immutable.js do.
• Write-heavy contention moves, it doesn't vanish — with an atomic swap, two writers can still clash. Use compareAndSet in a retry loop rather than blind set, or accept a lock on the (rare) write path.
• Ceremony — constructors, builders, withX() methods and defensive copies are more typing than a setter. Records, frozen dataclasses and const cut most of it away.

Where it shines

• Configuration and lookup tables — read constantly by everything, changed rarely by one reloader. The atomic-swap idiom was practically invented for this.
• Value objects — Money, Point, LocalDate, Currency, IDs. Small, shared everywhere, and safe map keys precisely because their hash can never change.
• Messages between threads — anything you hand to a queue, an executor, a channel or an actor should be immutable, so sender and receiver can't stomp on each other after the handoff.
• Functional and actor styles — Clojure, Erlang/Elixir and Akka build their entire concurrency story on "never mutate shared data", which is why they need so few locks.
• Caches and snapshots — a cached immutable result can be handed to every caller with no defensive copying at all.

One line per language

• Java — record gives you final fields, value equality and the final-field publication guarantee; List.copyOf / Map.copyOf make truly unmodifiable copies; AtomicReference holds the one mutable pointer.
• Python — tuple, frozenset and @dataclass(frozen=True); rebinding a module-level or attribute reference is atomic under the GIL, which makes the swap idiom easy (use a lock only around read-modify-write).
• C++ — const members and const methods; share as std::shared_ptr<const Config> and swap it with std::atomic<std::shared_ptr<const T>> so readers never lock.
• Go — structs are values, so passing one copies it; keep the shared thing a sync/atomic.Pointer or, better, follow the proverb "don't communicate by sharing memory; share memory by communicating" and send immutable values over a channel.

Make it immutable when...

• Many threads read it and few (or none) change it — config, feature flags, routing tables, pricing rules, compiled regexes, lookup maps. Readers never block each other and never need a lock.
• It's a value — money, dates, coordinates, identifiers, units. Its identity is its data, so there is no reason it should ever mutate, and it becomes a safe map/set key for free.
• It crosses a thread boundary — anything handed to a queue, executor, channel, actor or callback. Immutable payloads mean sender and receiver can't corrupt each other after the handoff.
• You want safe publication without ceremony — final fields let you share the object through a plain field or a plain HashMap with no volatile and no lock.

Keep it mutable when...

• Writes are frequent and the object is large — rebuilding a big structure on every edit will cost more than a well-scoped lock. Reach for a persistent data structure first, a lock second.
• The thing genuinely has a lifecycle — an in-progress Order, a game world, a connection pool. Model those as mutable entities, but build them out of immutable values.
• It's confined to one thread anyway — a local buffer or a per-request builder is not shared, so mutating it is free of risk. (Build mutably in private, then freeze and publish.)
• You need in-place performance — tight numeric loops over big arrays are the classic case where copying is simply not an option.