Volatile guarantee safe publication of a mutable object?

Question

By reading Java Concurrency in Practice

I can see:

To publish an object safely, both the reference to the object and the object\'s state must be

Answer 1

We need to show that constructing an object and assigning it to a volatile variable happens before it is read from that variable.

From JLS Chapter 17:

If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).

So, construction of an object happens before it is assigned to a volatile variable, from the point of view of that thread.

If an action x synchronizes-with a following action y, then we also have hb(x, y).

And:

If hb(x, y) and hb(y, z), then hb(x, z).

If we could show that writing the volatile variable (action y) synchronizes-with reading the variable (action z), we could use the transitivity of happens-before to show that constructing the object (action x) happens-before reading the object. Luckily:

A write to a volatile variable v (§8.3.1.4) synchronizes-with all subsequent reads of v by any thread (where "subsequent" is defined according to the synchronization order).

Therefore, we can see that a properly constructed object is visible to any thread when published this way.

Answer 2

volatile can only guarantee that the reference is visible to another thread but it doesn't have synchronization of object construction which it refers to.

Yes. You are right. You can find more details of internals about volatile variables in below question:

Difference between volatile and synchronized in Java

So how can it guarantee that the mutable object is properly constructed, what is the thread that is constructing this object is interrupted by another thread?

You have to use other programming constructs for thread safety : Using synchronized constructs or alternatives of synchronized constructs.

Refer to below related SE question:

Avoid synchronized(this) in Java?

Answer 3

Reads and writes are atomic for all variables declared volatile (including long and double variables).

Consequence: volatile guarantees, among others, that the variable is always read from the memory shared by all threads - if the value is published in a volatile variable, it must be fully constructed before.
In other words, if a volatile value is not published, then no other threads will know about it - most probably the result of 'construction in progress' may reside in the CPU cache or in the memory that JVM uses as "space I'm using for my own purposes; you puny Java code, don't ask what's in it, it's not your business".