Java 多线程 - 加入 CPU 繁重的线程和 volatile 关键字

Question

所以，在一些工作面试之后，我想编写一个小程序来检查 i++ 在 java 中是否真的是非原子的，并且在实践中应该添加一些锁定来保护它。事实证明你应该这样做，但这不是这里的问题。

所以我在这里写了这个程序只是为了检查它。

问题是，它挂了。似乎主线程卡在t1.join() 行，即使两个工作线程都应该因为上一行的stop = true 而完成。

我发现悬挂停止如果：

• 我在工作线程中添加了一些打印（如在 cmets 中），可能导致工作线程有时放弃 CPU 或
• 如果我将标志boolean stop 标记为volatile，导致立即写入 被工作线程看到，或者
• 如果我将计数器标记为 tas volatile... 我不知道是什么原因导致未挂起。

有人可以解释发生了什么吗？为什么我会看到挂起，为什么在这三种情况下它会停止？

public class Test {   

    static /* volatile */ long t = 0;
    static long[] counters = new long[2]; 
    static /* volatile */ boolean stop = false;

    static Object o = new Object();
    public static void main(String[] args) 
    {
        Thread t1 = createThread(0);
        Thread t2 = createThread(1);

        t1.start();
        t2.start();

        Thread.sleep(1000);

        stop = true;

        t1.join();
        t2.join();

        System.out.println("counter : " + t + " counters : " + counters[0] + ", " + counters[1]  + " (sum  : " + (counters[0] + counters[1]) + ")");

    }

    private static Thread createThread(final int i)
    {
        Thread thread = new Thread() { 
            public void run() {
                while (!stop)
                {
//                  synchronized (o) {                      
                        t++;
//                  }

//                  if (counters[i] % 1000000 == 0)
//                  {
//                      System.out.println(i + ")" + counters[i]); 
//                  }
                    counters[i]++;
                }
            }; 
        };
        return thread;
    }
}

Answer 1

似乎主线程卡在t1.join() 行，即使两个工作线程都应该完成，因为上一行的stop = true。

在没有volatile、锁定或其他安全发布机制的情况下，JVM 没有义务永远使stop = true 对其他线程可见。特别适用于您的情况，当您的主线程休眠一秒钟时，JIT 编译器将您的 while (!stop) 热循环优化为相当于

if (!stop) {
    while (true) {
        ...
    }
}

这种特殊的优化被称为“提升”循环外的读取操作。

我发现如果：

• 我在工作线程中添加了一些打印（如在 cmets 中），可能导致工作线程有时会放弃 CPU

不，这是因为PrintStream::println 是一个同步方法。所有已知的 JVM 都会在 CPU 级别发出内存栅栏，以确保“获取”操作（在本例中为锁定获取）的语义，这将强制重新加载 stop 变量。这不是规范要求的，只是一种实现选择。

• 如果我将标志 boolean stop 标记为 volatile，则会导致工作线程立即看到写入

该规范实际上没有关于何时必须对其他线程可见易失性写入的挂钟时间要求，但在实践中，可以理解它必须“很快”变得可见。因此，此更改是确保对stop 的写入安全发布到其他读取它的线程并随后被其他线程观察的正确方法。

• 如果我将计数器 t 标记为易失性...为此，我不知道是什么导致了取消挂起。

这些又是 JVM 为确保 volatile 读取的语义所做的间接影响，这是另一种“获取”线程间操作。

总而言之，除了使stop 成为易失性变量的更改之外，由于底层 JVM 实现的意外副作用，您的程序从永远挂起切换到完成，为简单起见，它会进行更多的线程刷新/无效- 超出规范要求的本地状态。

Answer 2

这些可能是可能的原因：

• 将“stop”标记为 volatile 可防止其值被缓存在工作线程状态（例如寄存器）中
• 将“t”标记为易失性可确保在访问“t”时读取更新的值。但是，如果 JVM 将这些变量安排得彼此靠近，这种行为也可能会获得“停止”的更新值，因此它们可能会被读取并存储在同一个“缓存行”中。尝试添加 @Contended 注释以查看在这种情况下行为是否仍然存在。您可能会在以下位置找到更多信息：https://en.wikipedia.org/wiki/False_sharing、https://mechanical-sympathy.blogspot.am/2011/07/false-sharing.html、https://blogs.oracle.com/dave/entry/java_contented_annotation_to_help
• 调用“System.out.println()”实际上会执行系统调用，因此会转换到“本机调用堆栈”，这可能也会导致“处理器缓存”被清除。 What does a JVM have to do when calling a native method?

如果您有兴趣深入研究该主题，那么我建议您阅读“Brian Goetz 的 Java 并发实践”一书。

Answer 3

将变量标记为 volatile 是 JVM 的一个提示，当该变量更新时，它会在线程/内核之间刷新/同步相关的缓存段。将 stop 标记为 volatile 会有更好的行为（但并不完美，在线程看到更新之前，您可能需要在线程上执行一些额外的操作）。

将t 标记为 volatile 让我不明白为什么它会起作用，可能是因为这是一个如此小的程序，t 和 stop 在缓存中位于同一行，所以当一个被刷新时/synced 另一个也一样。

System.out.println 是线程安全的，所以内部会进行一些同步。同样，这可能会导致缓存的某些部分在线程之间同步。

如果有人可以对此进行补充，请这样做，我也很想听到更详细的答案。

Answer 4

实际上，它确实做到了——在多个线程之间提供对字段的一致访问，您可以看到它。

如果没有volatile关键字，多线程对字段的访问不能保证一致，编译器可以引入一些优化，比如缓存在CPU寄存器中，或者不从CPU内核本地缓存写出到外部内存或共享缓存.

---

对于具有非易失性stop 和易失性t 的部分

根据 JSR-133 Java 内存模型规范，在 volatile 字段更新之前的所有写入（对任何其他字段）都是可见的，它们是 happened-before 操作。

当您在增加t 后设置stop 标志时，循环中的后续读取将看不到它，但下一次增加 (volatile-write) 将使其可见。 p>

---

另见

Java Language Specification: 8.3.1.4. volatile Fields

An article about Java Memory Model, from the author of Java theory and practice