17

Reading "Java Concurrency In Practice", there's this part in section 3.5:

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

Besides the obvious thread safety hazard of creating two instances of Holder, the book claims a possible publishing issue can occur.

Furthermore, for a Holder class such as

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

an AssertionError can be thrown!

How is this possible? The only way I can think of that can allow such ridiculous behavior is if the Holder constructor would not be blocking, so a reference would be created to the instance while the constructor code still runs in a different thread.

Is this possible?

1
  • Is that means all the field in an object must be final. Is there anyway i can prove myself that this can happen. I tried please help
    – John
    Feb 22, 2011 at 17:37

7 Answers 7

18

The reason why this is possible is that Java has a weak memory model. It does not guarantee ordering of read and writes.

This particular problem can be reproduced with the following two code snippets representing two threads.

Thread 1:

someStaticVariable = new Holder(42);

Thread 2:

someStaticVariable.assertSanity(); // can throw

On the surface it seems impossible that this could ever occur. In order to understand why this can happen, you have to get past the Java syntax and get down to a much lower level. If you look at the code for thread 1, it can essentially be broken down into a series of memory writes and allocations:

  1. Alloc memory to pointer1
  2. Write 42 to pointer1 at offset 0
  3. Write pointer1 to someStaticVariable

Because Java has a weak memory model, it is perfectly possible for the code to actually execute in the following order from the perspective of thread 2:

  1. Alloc Memory to pointer1
  2. Write pointer1 to someStaticVariable
  3. Write 42 to pointer1 at offset 0

Scary? Yes but it can happen.

What this means though is that thread 2 can now call into assertSanity before n has gotten the value 42. It is possible for the value n to be read twice during assertSanity, once before operation #3 completes and once after and hence see two different values and throw an exception.

EDIT

According to Jon Skeet, the AssertionError migh still occur with Java 8 unless the field is final.

8
  • @Jared: I had forgotten that's only guaranteed for final fields. IIRC, the ECMA CLI specification is weak in this respect too, but the .NET memory model makes all writes effectively volatile. That's only IIRC though :)
    – Jon Skeet
    Oct 25, 2009 at 17:27
  • @Jon you are correct on the .Net and ECMA angles. It makes for interesting fun though when reviewing changes to the F# libs and code base as they conform to the ECMA model.
    – JaredPar
    Oct 25, 2009 at 17:29
  • Scary indeed. I learned from you answer something I had no idea regarding java memory model - This scares me because it can effectively mean 90% of every java code in the world is broke. Further more, the speed of your answer amazes me. From my calculation it took you a total of ~5min to answer my question! Thank you very much for the effort. Oct 25, 2009 at 17:34
  • The good guys at sun explain the described above "Happens Before" relationship. java.sun.com/javase/6/docs/api/java/util/concurrent/… (#see Memory Consistency Properties section) Nov 2, 2009 at 14:55
  • @JaredPar You should remove your edit - it is possible for n != n to return true under the current memory model (Java 5+).
    – assylias
    Sep 4, 2013 at 17:08
13

The Java memory model used to be such that the assignment to the Holder reference might become visible before the assignment to the variable within the object.

However, the more recent memory model which took effect as of Java 5 makes this impossible, at least for final fields: all assignments within a constructor "happen before" any assignment of the reference to the new object to a variable. See the Java Language Specification section 17.4 for more details, but here's the most relevant snippet:

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

So your example could still fail as n is non-final, but it should be okay if you make n final.

Of course the:

if (n != n)

could certainly fail for non-final variables, assuming the JIT compiler doesn't optimise it away - if the operations are:

  • Fetch LHS: n
  • Fetch RHS: n
  • Compare LHS and RHS

then the value could change between the two fetches.

6
  • Is that means all the field in an object must be final. Is there anyway i can prove myself that this can happen. I tried please help
    – John
    Feb 22, 2011 at 17:37
  • javap shows that it doesn't optimize it away so your assumption is correct: 1: getfield #2 4: aload_0 5: getfield #2 8: if_icmpeq 21
    – Eran Medan
    Jun 7, 2013 at 22:27
  • What you quote is about final semantics. But for this statement: Holder holder = new Holder(), latest JMM can guarantee <init> is executed before astore? could you tell me the section in JLS.
    – Chao
    Aug 29, 2016 at 15:54
  • 1
    @Richard: Not at all sure, I'm afraid.
    – Jon Skeet
    Aug 29, 2016 at 18:25
  • @JonSkeet That means it is still possible that a partially initialized object can be seen by another thread if no synchronization is applied
    – Chao
    Aug 30, 2016 at 3:13
1

Well, in the book it states for the first code block that:

The problem here is not the Holder class itself, but that the Holder is not properly published. However, Holder can be made immune to improper publication by declaring the n field to be final, which would make Holder immutable; see Section 3.5.2

And for the second code block:

Because synchronization was not used to make the Holder visible to other threads, we say the Holder was not properly published. Two things can go wrong with improperly published objects. Other threads could see a stale value for the holder field, and thus see a null reference or other older value even though a value has been placed in holder. But far worse, other threads could see an up-todate value for the holder reference, but stale values for the state of the Holder.[16] To make things even less predictable, 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 assertSanity can throw AssertionError.

I think JaredPar has pretty much made this explicit in his comment.

(Note: Not looking for votes here -- answers allow for more detailed info than comments.)

0

The basic issue is that without proper synchronization, how writes to memory may manifest in different threads. The classic example:

a = 1;
b = 2;

If you do that on one thread, a second thread may see b set to 2 before a is set to 1. Furthermore, it's possible for there to be an unbounded amount of time between a second thread seeing one of those variables get updated and the other variable being updated.

0

I was also very puzzled by that example. I found a website that explains the topic thoroughly and readers might find useful: https://www.securecoding.cert.org/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects

Edit: The relevant text from the link says:

the JMM permits compilers to allocate memory for the new Helper object and to assign a reference to that memory to the helper field before initializing the new Helper object. In other words, the compiler can reorder the write to the helper instance field and the write that initializes the Helper object (that is, this.n = n) so that the former occurs first. This can expose a race window during which other threads can observe a partially initialized Helper object instance.

0
-1

looking at this from a sane perspective, if you assume that the statement

if(n != n)

is atomic (which I think is reasonable, but i dont know for sure), then the assertion exception could never be thrown.

2
  • does anyone care to explain the -1?
    – twolfe18
    Oct 31, 2009 at 22:49
  • Didn't downvote but your assumption that n !=n is wrong. Nov 6, 2020 at 8:20
-1

This example comes under "A reference to the object containing the final field did not escape the constructor"

When you instantiate a new Holder object with the new operator,

  1. the Java virtual machine first will allocate (at least) enough space on the heap to hold all the instance variables declared in Holder and its superclasses.
  2. Second, the virtual machine will initialize all the instance variables to their default initial values. 3.c Third, the virtual machine will invoke the method in the Holder class.

please refer for above: http://www.artima.com/designtechniques/initializationP.html

Assume: 1st Thread starts 10:00 am, it calls instatied the Holder object by making the call of new Holer(42), 1) the Java virtual machine first will allocate (at least) enough space on the heap to hold all the instance variables declared in Holder and its superclasses. -- it will 10:01 time 2) Second, the virtual machine will initialize all the instance variables to their default initial values -- it will start 10:02 time 3) Third, the virtual machine will invoke the method in the Holder class.-- it will start 10:04 time

Now Thread2 started at --> 10:02:01 time, and it will make a call assertSanity() 10:03, by that time n was initialized with default of Zero, Second thread reading the stale data.

//unsafe publication public Holder holder;

if you make the public final Holder holder will resolve this issue

or

private int n; if you make the private final int n; will resole this issue.

please refer : http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html under section of How do final fields work under the new JMM?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.