CODEWITHSUNDEEP
javaconcurrency
GJ13
GJ13

Reputation: 488

Improper publication of Java Object Reference

The below example is from the book "Java Concurrency in Practice" by Brian Goetz, Chapter 3, Section 3.5.1. This is an example of Improper publication of objects:

class SomeClass {
    public Holder holder;

    public void initialize() {
        holder = new Holder(42);
    }
}

public class Holder {
  private int n;
  public Holder(int n) { this.n = n; }

  public void assertSanity() {
    if (n != n)
      throw new AssertionError("This statement is false");
  }
}

It says that the Holder could appear to another thread in an inconsistent state and another thread could observe a partially constructed object. How can this happen? Could you give a scenario using the above example?

Also it goes on to say that there are cases when a thread may see a stale value the first time it reads a field and then a more up to date value the next time, which is why the assertSanity can throw AssertionError. How can the AssertionError be thrown?

From further reading, one way to fix this problem is to make Holder immutable by making the variable n final. For now, let us assume that Holder is not immutable but effectively immutable.

To safely publish this object, do we have to make holder initialization static and declare it as volatile (both static initialization and volatile or just volatile)?

Something like this:

public class SomeClass {
    public static volatile Holder holder = new Holder(42);
}

Upvotes: 27

Views: 2001

Answers (4)

John Vint
John Vint

Reputation: 40256

You can imagine creation of an object has a number of non-atomic functions. First you want to initialize and publish Holder. But you also need to initialize all the private member fields and publish them.

Well, the JMM has no rules for the write and publication of the holder's member fields to happen before the write of the holder field as occurring in initialize(). What that means is that even though holder is not null, it is legal for the member fields to not yet be visible to other threads.

You may end up seeing something like

public class Holder {
    String someString = "foo";
    int someInt = 10;
}

holder may not be null but someString could be null and someInt could be 0.

Under an x86 architecture this is, from what I know, impossible to happen but may not be the case in others.

So next question may be "Why does volatile fix this?" The JMM says that all writes that happen prior to the volatile store are visible to all subsequent threads of the volatile field.

So if holder is volatile and you see holder is not null, based on volatile rules, all of the fields would be initialized.

To safely publish this object, do we have to make holder initialization static and declare it as volatile

Yes, because as I mentioned if the holder variable is not null then all writes would be visible.

How can the AssertionError be thrown?

If a thread notices holder not to be null, and invokes AssertionError upon entering the method and reading n the first time may be 0 (the default value), the second read of n may now see the write from the first thread.

Upvotes: 17

Tom
Tom

Reputation: 181

The problem which you ask about is caused by JVM optimizations and the fact that simple object creation:

MyClass obj = new MyClass()

isn't always done by steps:

  1. Reserve memory for new instance of MyClass on the Heap
  2. Execute constructor to set internal properties values
  3. Set 'obj' reference to address on the Heap

For some optimization purposes JVM can do it by steps:

  1. Reserve memory for new instance of MyClass on the Heap
  2. Set 'obj' reference to address on the Heap
  3. Execute constructor to set internal properties values

So, imagine if two threads want to access MyClass object. First one creates it but due to JVM it executes 'optimized' set of steps. If it will execute only step 1 and 2 (but wont do 3) than we can have a serious problem. If second thread uses this object (it wont be null because it already points to reserved part of memory on the Heap) than it's properties will be incorrect which can lead to nasty things.

This optimization wont happen if reference will be volatile.

Upvotes: 0

fgb
fgb

Reputation: 18559

public class Holder {
  private int n;
  public Holder(int n) { this.n = n; }

  public void assertSanity() {
    if (n!=n)
      throw new AssertionError("This statement is false");
  }
}

Say one thread creates an instance of Holder, and passes the reference to another thread, which calls assertSanity.

The assignment to this.n in the constructor occurs in one thread. And two reads of n occur in another thread. The only happens-before relation here is between the two reads. There is no happens-before relation involving the assignment and any of the reads.

Without any happens-before relations, statements can be reordered in various ways, so from the perspective of one thread, this.n = n can occur after the constructor has returned.

This means that the assignment can appear to occur in the second thread after the first read and before the second, resulting in inconsistent values. The can be prevented by making n final, which guarantees that the value is assigned before the constructor finishes.

Upvotes: 3

Tassos Bassoukos
Tassos Bassoukos

Reputation: 16152

The Holder class is OK, but the class someClass can appear in an inconsisten state - between creation and the call to initialize() the holder instance variable is null.

Upvotes: -1

Related Questions