线程之间，同步和提升之间可变变量的一致性

Question

On my machine the following code runs indefinitely (Java 1.7.0_07):

public static void main(String[] args) throws InterruptedException {
    Thread backgroundThread = new Thread(new Runnable() {
        public void run() {
            int i = 0;
            while (!stopRequested) {
                i++;
            }
        }
    });
    backgroundThread.start();
    TimeUnit.SECONDS.sleep(1);
    stopRequested = true;
}

However, add a single lock object and a single synchronized statement NOT around stopRequested (in fact, nothing occurs in the synchronized block), and it terminates:

public static void main(String[] args) throws InterruptedException {
    Thread backgroundThread = new Thread(new Runnable() {
        public void run() {
            Object lock = new Object();
            int i = 0;
            while (!stopRequested) {
                synchronized (lock) {}
                i++;
            }
        }
    });
    backgroundThread.start();
    TimeUnit.SECONDS.sleep(1);
    stopRequested = true;
}

In the original code, the variable stopRequested is "hoisted", becoming:

if (!stopRequested)
    while (true)
        i++;

However, in the modified version, it seems this optimization is not occurring, why? (In fact, why is synchronized not optimized away entirely?)

Answer 1

VM is unable to reason that the lock is not synchronized by other threads, so it cannot be optimized away.

Per Java Memory Model, all synchronization blocks are totally ordered, and this order (on the same lock) helps to establish happens-before relation. That's why VM can't remove a synchronization block; unless VM can prove that only one thread is ever synchronizing on an object, then all these sync blocks can be removed with no impact on happens-before relation.

If the lock is a local object, VM could do escape analysis to elide the lock. We've been hearing about escape analysis for years, but as the example shows, and as I've tested not very long ago, it doesn't seems to be working yet.

There might be a reason why lock elision isn't being done. The optimization is great for code that uses local Vector or StringBuffer etc. But that's only in old codes; nobody does that for a long time.

Some code might even depend on the stronger pre-java-5 model, in which no lock can be elided ever. There might be many programs, similar to OP's crafted example, that are incorrect in the new model, but have been working for years in the past. Lock elision may break these programs.

Answer 2

While this might look like a memory visibility issue, it is usually a JIT optimisation issue in simple examples. This is because the JIT can detect whether you are modifying the flag in that thread can inline it if you don't. Effectively turning it into an infinite loop.

One way you can tell this is that visibility issues are short lived, usually too short for you to see. While they are random they are usually one micro-second to a milli-second. ie until the thread context switches and when it runs again it doesn't keep the old value with it. The fact you can see examples where it consistently turned into an infinite loop which never "detects" the change is a give away.

If you just slow down the loop with a Thread.sleep(10) this can prevent it running long enough to be compiled. It has to loop 10,000+ times to be optimised. This usually "fixes" the problem.

Adding thread safety code such as using a volatile variable or adding a synchronized block can prevent optimisation from being made.