使用同步时，JVM如何保证在引用对象中成员变量修改的可见性？

Question

I want to know how does the JVM guarantee the visibility of member variable modifications in the referenced object when using synchronized.

I know synchronized and volatile will provide visibility for variable modifications.

class Test{
    public int a=0;

    public void modify(){
        a+=1;
    }
}


//Example:

// Thread A:
 volatile Test test=new Test();
 synchronized(locker){
   test.modify();
 }

// then thread B:
synchronized(locker){
   test.modify();
}

// Now, I think test.a==2 is true. Is it ok? How JVM implements it?
// I know the memory barrier, does it flush all cache to main storage?

Thread A call modify in a sychronized block first, and then pass the object to thread B (Write the reference to a volatile variable.). Then thread B call modify again (in synchronized ).

Is there any guarantee for a==2? And how is the JVM implemented?

Answer 1

Visibility between threads is enforced with Memory Barriers/Fences . In case of synchronized block JVM will insert a memory barrier after the execution of the block completes.

JVM implements memory barriers with CPU instruction eg a store barrier is done with sfence and load barrier is done with lfence instruction on x86. There is also mfence and possibly other instructions which can be specific to CPU architecture.

Answer 2

For your (still incomplete!) example, if we can assume the following:

1. The code in thread A initializing test is guaranteed to run before thread B uses it.
2. The locker variable contains a reference to the same object for threads A & B.

then we can prove that a == 2 will be true at the point you indicate. If precondition 1 is not guaranteed, then thread B may get an NPE. If precondition 2 is not guaranteed (ie threads A and B may synchronize on different objects) then there is not a proper happens-before relationship to ensure that thread B sees the result of thread A's actions on a .

(@NathanHughes commented that the volatile is unnecessary. I wouldn't necessarily agree with that. It depends on details of your example that you still haven't show us.)

---

How JVM implements it?

The actual implementation is Java platform and (in theory) version specific. The JVM spec Memory Model places constraints on how a program that obeys "the rules" will behave. It is entirely implementation specific how that actually happens.

I know the memory barrier, does it flush all cache to main storage?

That is implementation specific too. There are different kinds of memory barrier that work in different ways. The JIT compiler will emit native code that uses the appropriate instructions to meet the guarantees required by the JLS. If there is a way to do this without doing a full cache flush then the implementation may do that.

(There is a JVM command line option to tell the JIT compiler to output the native code. If you really want to know what is happening under the hood, that is a good place to start looking.)

But if you are trying to understand / analyze your application's thread-safety, you should be doing it in terms of the Java Memory Model. Also, use higher level concurrency abstractions that allow you to avoid the lower level pitfalls.