java - 缓存一致性在无限循环演示中不起作用

Question

this question中有这么一句话:

All caches are coherent. That is, you will never had two different values for the same memory location. This coherency is maintained by a version of the MESI protocol

我的问题是为什么下面代码块中的iv.stop总是false，看来缓存一致性没有生效。顺便说一句，我电脑的 CPU 是 i7-4700HQ。

我绝对知道共享变量stop的读取操作和写入操作之间不存在happens-before关系，这是Java中的数据竞争。我只是想知道为什么缓存一致性不起作用。由于线程 t2 更改了其运行核心中 stop 的缓存，因此根据缓存一致性，线程 t1 正在运行的核心缓存似乎应该看到此更改。

public class InfiniteLoop {
    boolean stop = false;

    Boolean another = null;

    public static void main(String[] args) {

        final InfiniteLoop iv = new InfiniteLoop();

        Thread t1 = new Thread(() -> {
            System.out.println("t1 iv address-->"+iv); //t1 iv address-->com.nestvision.thread.InfiniteLoop@48b96cb8
            while (!iv.stop) {
                //Not System.out.println(iv.stop) here to avoid 
                //a lock action of PrintStream object.
                iv.another = iv.stop;
            }
            System.out.println("done");
        });

        Thread t2 = new Thread(() -> {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("t2 iv address-->"+iv);//t2 iv address-->com.nestvision.thread.InfiniteLoop@48b96cb8
            iv.stop = true;
            System.out.println("t2 end");
        });
        t2.start();
        t1.start();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(iv.another); //this will print 'false'
    }
}

Answer 1

首先，最后的打印可以在线程开始之前打印，并且肯定在线程结束之前打印。您可能想要使用一些 java 并发类来阻塞主线程，直到其他线程完成尽管这可能会无限循环并永远等待，直到您执行下面的修复。

另一个问题是您的 stop 变量不是 volatile ，因此不同的线程可能看不到该值。

这个其他答案包含有关跨处理器的 boolean 值和 L1/L2 缓存的信息 How is memory inconsistency different from thread interleaving?

相关引用:

Thread A reads the boolean value: it will necessarily read false (see the previous bullet point). When this read happens, it might happen that some memory pages, including the one containing that boolean, will be cached into Core 1's L1 cache, or L2 cache -- any cache local to that specific core.

Thread A negates and stores the boolean value: it will store true now. But the question is: where? Until a happens-before occur, Thread A is free to store this new value only on the local cache to the Core running the thread. Therefore, it is possible that the value will be updated on Core 1's L1/L2 cache, but will remain unchanged in the processor's L3 cache or in RAM.

After some time (according to your wall clock), Thread B reads the boolean value: if Thread A didn't flush the changes into L3 or RAM, it's entirely possible that Thread B will read false. If Thread A, on the other hand, had flushed the changes, it is possible that Thread B will read true (but still not guaranteed -- Thread B might have received a copy of Thread M's view of the memory and, due to the lack of happens-before, it won't go to the RAM again and will still see the original value).

The only way to guarantee anything is to have an explicit happens-before: it would force Thread A to flush its memory, and would force Thread B to read not from a local cache, but truly read it from the "authoritative" source.

Without a happens-before, as you can see form the example above, anything can happen, no matter how much time (from your perspective) elapses between events in different threads.

...

If that boolean variable is marked as volatile...then, only then, Thread B is guaranteed to see true (ie, otherwise there are no guarantees at all).

The reason is that volatile helps establish happens-before relationships. It goes as follows: a write to a volatile variable happens-before any subsequent read to the same variable.