Object creation (state initialisation) and thread safety

Question

I am look into the book \"Java Concurrency in Practice\" and found really hard to believe below quoted statement (But unfortunately it make sense).

http://www.informit.c

Answer 1

When creating a new object things happen sequentially. I don't know the precise order, but it's something like: allocate the space and initialize it to zeroes, then set the fields that get constant values, then set the fields that get calculated values, then run the constructor code. And, of course, it's got to initialize the subclasses in there somewhere.

So if you try to work with an object that is still being constructed, you can see odd, invalid values in the fields. This doesn't usually happen, but ways to do it:

• Reference a field that doesn't yet have a value during an assignment to another field.

• Reference a value in the constructor that doesn't get assigned till later in the constructor.

• Reference a field in an object in a field in an object that was just read from an ObjectInputStream. (OIS often takes a long time to put values in objects it's read.)

• Before Java 5, something like:

  public volatile MyClass  myObject;
  ...
  myObject = new MyClass( 10 );
  

  could make trouble because another thread could grab the reference to myObject before the MyClass constructor was finished and it would see bad values (zero instead of 10, in this case) inside the object. With Java 5, the JVM is not allowed to make myObject non-null until the constructor is finished.

• And today you can still set myObject to this within the constructor and accomplish the same thing.

If you're clever, you can also get hold of Class fields before they've been initialized.

In your code example, (n != n) would be true if something changed the value between the two reads of n. I guess the point is n starts as zero, get's set to something else by the constructor, and assertSanity is called during the construction. In this case, n is not volatile so I don't think the assert will ever be triggered. Make it volatile and it will happen once every million times or so if you time everything precisely right. In real life this kind of problem happens just often enough to wreak havoc but rarely enough that you can't reproduce it.