Java多线程与方法调用结合使用？

Question

I met the following Java class on the internet:

public class Lock1 implements Runnable {
int b=100;
public synchronized void m1() throws Exception {
    b=1000;
    Thread.sleep(50);
    System.out.println("b="+b);
}

public synchronized void m2() throws Exception {
    Thread.sleep(30);
    //System.out.println("m2");
    b=2000;
}

public void run() {
    try {m1();}
    catch(Exception e) {
        e.printStackTrace();
    }
}

public static void main(String[] args) throws Exception {
    Lock1 tt=new Lock1();
    Thread t = new Thread(tt);
    t.start();

    tt.m2();
    System.out.println(tt.b);
}
}

Tried running this a lot of times, the result is almost always:

     1000
     b=1000

In my original guess, I thought the first line should be "2000", since tt.m2() is just a method invocation(not a thread), the main method should continue with its execution and get the resulting "b" as the one has been assigned value 2000 in method m2.

The second try that I did is to uncomment out the

 System.out.println("m2") 

in m2 method.Suprisingly, the result will be nearly always:

 m2
 2000
 b=1000

Why adding a statement in the m2 method, will cause the output value of tt.b to be changed?

Sorry I am quite confused here about the difference between threads and method invocation, hope experts can help out!

Answer 1

Synchronization in the Java sense combines several things. In this case these points are interesting:

• mutual exclusion
• memory barriers for readers
• memory barriers for writers

After entering a synchronized block (or method) you have got two guarantees: You have the lock (mutual exclusion) and that the JVM and the compiler will discard any cache for the for the synchronization object . This means an access to this.b will fetch the actual value for 'b' from the RAM and not from any cache but only once . Then it will work with the cached copy again.

Leaving a synchronized block in turn guarantees that the CPU flushes all dirty (ie written) caches to the memory.

The point in your stuff is: System.out.println(tt.b); is in no way synchronized which means the access to it has not crossed a defined memory barrier. So although the other thread has written a new value for b and flushed it to the RAM the main thread has no idea, that it should read b from RAM and not from its own cache.

The solution is:

synchronized(tt){
    System.out.println(tt.b);
}

This meets the golden rule, that if something is synchronized then every access to it should be synchronized and not only half of the accesses.

And regarding your added System.out : There are three things:

First: It is slow (compared to some memory fiddling). This means that in the meantime the CPU or the JVM might decide for themselves, that a new look to tt might be appropriate

Second: It is big (compared to some memory fiddling). This means that the touched code alone might evict tt from the caches.

Third: It is synchronized internally. This means that you crossed some memory barriers (which might have nothing to do with your tt - who knows). But these might also have some effect.

This is the lead rule of multithreading debugging: Adding System.out in order to catch errors will, according to Murphy, actually hide the problem.

Answer 2

I guess this is JVM implementation specific.

Basically, each thread has its's own copy (view) of the object variables and the way they are synced back and forth is not determined.

Answer 3

The most likely cause is that System.out.println is slow. The cause of the "unexpected" results is because of a race condition between the delay ( Thread.sleep ) and the overhead of opening the output stream ( System.out.println ).