How do final instance fields interact with the Java Memory Model to provide safe publication, and what design rule does this imply for immutable objects?

## Background: why visibility is even a problem In a multithreaded program, one thread writing a field does **not** automatically mean another thread will *see* that write. The **Java Memory Model (JMM)** is the part of the spec that defines when writes by one thread become visible to reads by another. Without proper synchronization, a thread can observe a **partially constructed** object — for example, a reference that is non-null but whose fields still hold default values (0/null) — because the compiler/CPU may reorder the field writes relative to the publication of the reference. **Safe publication** means making an object visible to other threads in a way that guarantees they see it fully and correctly initialized. ## The final-field guarantee The JMM grants `final` fields a special rule, sometimes called **initialization safety** or the **final-field freeze**: > When a constructor completes normally, the JMM inserts a conceptual *freeze* of the object's final fields. Any thread that reads a reference to that object — even through an ordinary, unsynchronized field — is guaranteed to see at least the values the final fields had at the freeze, **and** the values (at construction time) of everything those final fields transitively reference. In plain terms: **correctly constructed objects with final fields can be safely read by other threads without any synchronization**, with respect to those final fields. This is unusual — normally you need `volatile`, `synchronized`, or another happens-before edge to publish data safely. final fields are the one mechanism that bakes safe publication into construction itself. ## The critical precondition: do not let `this` escape The guarantee only holds if the object is **not made visible to other threads before its constructor finishes**. If the constructor lets the `this` reference *escape* early, another thread may grab the object **before** the freeze and see uninitialized finals. Ways `this` escapes during construction: - Storing `this` in a static or shared field. - Passing `this` to a method that publishes it (e.g. registering an event listener, adding to a shared collection). - Starting a thread that captures `this` from inside the constructor. - Calling an overridable method that does any of the above. So the design rule is: **finish constructing before publishing; never leak `this` from a constructor.** ## Why non-final fields are different Non-final fields receive **no** initialization-safety guarantee. If you publish an object with non-final fields via a data race (e.g. assigning to an ordinary shared field), readers may see stale defaults. To publish such state safely you must use `volatile`, `final`, locks, or other happens-before machinery. ## The immutable-object design pattern This directly motivates the canonical **immutable object** recipe for lock-free sharing: 1. Make **all fields `final`**. 2. Make the object's state **not mutable** after construction (no setters; defensively copy mutable inputs/outputs). 3. Ensure **`this` does not escape** during construction. 4. The class is then effectively immutable and can be **freely shared across threads without synchronization**. ```java public final class Point { private final int x; private final int y; public Point(int x, int y) { this.x = x; this.y = y; } // no this escape public int x() { return x; } public int y() { return y; } } ``` A `Point` constructed on one thread and handed to others via any means is guaranteed to be seen fully initialized. ## Subtleties worth knowing - The guarantee covers what the final fields **transitively reference at construction time**, so a `final` field pointing at an array gives visibility of the array's *contents written during construction* — but later mutations of that array are not covered (which is why you also need true immutability). - This is precisely why `String`, the boxed primitives, and other JDK immutables are safe to share without locks. - It is the reason the double-checked-locking idiom for immutable holders can work when the held field is final, whereas with non-final fields you must use `volatile`. ## Summary final fields give the JMM's strongest construction guarantee: a fully constructed object's final fields (and what they reference at construction) are safely visible to any thread that later obtains the reference, with no synchronization — provided `this` never escaped during construction. This underwrites the immutable-object pattern as a first-class concurrency tool.