Does object construction guarentee in practice that all threads see non-final fields initialized?

  • A+
Category:Languages

The Java memory model guarantees a happens-before relationship between an object's construction and finalizer:

There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (§12.6) for that object.

As well as the constructor and the initialization of final fields:

An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields.

There's also a guarantee about volatile fields since, there's a happens-before relations with regard to all access to such fields:

A write to a volatile field (§8.3.1.4) happens-before every subsequent read of that field.

But what about regular, good old non-volatile fields? I've seen a lot of multi-threaded code that doesn't bother creating any sort of memory barrier after object construction with non-volatile fields. But I've never seen or heard of any issues because of it and I wasn't able to recreate such partial construction myself.

Do modern JVMs just put memory barriers after construction? Avoid reordering around construction? Or was I just lucky? If it's the latter, is it possible to write code that reproduces partial construction at will?

Edit:

To clarify, I'm talking about the following situation. Say we have a class:

public class Foo{     public int bar = 0;      public Foo(){         this.bar = 5;     }     ... } 

And some Thread T1 instantiates a new Foo instance:

Foo myFoo = new Foo();

Then passes the instance to some other thread, which we'll call T2:

Thread t = new Thread(() -> {      if (myFoo.bar == 5){          ....      } }); t.start(); 

T1 performed two (interesting to us) writes:

  1. T1 wrote the value 5 to bar of the newly instantiated myFoo
  2. T1 wrote the reference to the newly created object to the myFoo variable

For T1, we get a guarantee that write #1 happened-before write #2:

Each action in a thread happens-before every action in that thread that comes later in the program's order.

But as far as T2 is concerned the Java memory model offers no such guarantee. Nothing prevents it from seeing the writes in the opposite order. So it could see a fully built Foo object, but with the bar field equal to equal to 0.

 


Taking your example as the question itself - the answer would be yes, that is entirely possible. The initialized fields are visible only to the constructing thread, like you quoted. This is called safe publication (but I bet you already knew about this).

The fact that you are not seeing that via experimentation is that AFAIK on x86 (being a strong memory model), stores are not re-ordered anyway, so unless javac would re-ordered those stores that T1 did - you can't see that. But that is playing with fire, literately, this question and the follow-up (it's close to the same) here of a guy that (not sure if true) lost 12 milion of equipment

The JLS guarantees only a few ways to achieve the visibility. And it's not the other way around btw, the JLS will not say when this would break, it will say when it will work.

1) final field semantics

Notice how the example shows that each field has to be final - even if under the current implementation a single one would suffice, and there are two memory barriers inserted (when final(s) are used) after the constructor: LoadStore and StoreStore.

2) volatile fields (and implicitly AtomicXXX); I think this one does not need any explanations and it seems you quoted this.

3) Static initializers well, kind of should be obvious IMO

4) Some locking involved - this should be obvious too, happens-before rule...

Comment

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: