print()` 会使得线程局部缓存无效吗？

Question

在Java或Kotlin等JVM语言中，每个线程都拥有自己的“本地内存”，也称为“缓存”。当一个线程想要修改一个变量时，它首先会在自己的缓存中更新这个值，然后将修改同步到主内存中，主内存是线程间共享的。

下面的示例展示了一个线程未察觉到变化发生的情况：

class VolatileExample3 {
    var flag = false
    var a = 0

    fun write() {
        a = 1
        Thread.sleep(10) // 模拟IO操作的延迟
        flag = true
    }

    companion object {
        @JvmStatic
        fun test() {
            val example = VolatileExample3()
            val th = Thread { example.write() }
            th.start()
            while (!example.flag) {}
            println("a = ${example.a}")
        }
    }
}

在这个例子中，th线程执行write()方法，先更新a的值，然后暂停10毫秒，最后设置flag为true，表示写操作已完成。

主线程不断检查flag的值，直到它变为true，理论上这时write()应该已经完成。

我们期望输出是"a = 1"，这是写操作完成后正确的结果。

但是，由于存在“本地内存/缓存”，主线程可能会在while循环中看似卡住，因为它读取的是自己缓存中的flag值，并没有看到主内存中flag已被更新为true。

解决这个问题的一个明显答案是在flag上添加@Volatile注解，这样在对它进行读操作时会先使本地内存失效，确保从主内存加载最新值。

但我发现另一个解决方法是修改while循环如下：

while (!example.flag) {
    print("")
}

这个方法不使用@Volatile也能工作！我很好奇是否print()函数内部的“刷新缓存”操作会导致主线程的本地内存失效。如果是这样，其背后的机制是什么？

另外，我还发现如果在while循环前加上th.join()也同样有效。这些方法本质上是否相同？即一个线程的终止会通知所有其他线程，导致它们的本地内存失效吗？

Adriaan Stander · Answer

在Java编程语言中并没有所谓的“缓存”。缓存实际上是计算机硬件架构的一部分，不同的计算机其工作方式可能有所不同。

作为一名Java程序员，你的任务是确保你的代码遵循《Java语言规范》（JLS）中发布的规定。提供特定于你计算机的Java编译器（javac）、Java虚拟机（JVM）和Java运行时环境（JRE）的开发者的工作则是保证，如果你的代码遵守JLS的规则，那么他们的代码将兑现JLS所做出的承诺。

上次查看时，关于多线程访问变量的规则和承诺大多在第17章中描述，主要通过“同步”和“先行发生”关系来表达。

我找到了另一个解决方案，就是使用：...print()方法。

这可能在你当前使用的计算机、操作系统版本以及特定的JDK版本上工作。实际上，对于很多人和多种计算机来说，这种方法确实有效，但它并不是被保证一定有效的。

通过实验来找出什么“有效”什么是“无效”的方法并不可靠。我曾经在一家大型公司工作，该公司发布了一个违反规则的主要软件包。它在我们的办公室里通过了几周的严格测试。最初发布时，甚至在我们所有客户的计算机上都能“正常工作”。然而，后来我们的一个客户升级了他们的操作系统，软件就停止工作了。

另外我发现，在while循环前放置th.join()语句也可以工作。

这是保证有效的。JLS明确保证，线程A对共享变量所做的任何更改必须在其他线程调用A.join()之后变得对其可见。用JLS的术语来说，线程A所做的任何操作都“先行于”另一个线程中的A.join()调用返回。

epascarello · Answer

简短的回答是，根据Java内存模型（JMM）——Kotlin在JVM上运行所依赖的模型，你的程序是不正确的。

在子线程中写入flag和主线程随后读取它之间没有“先行发生”的关系。程序的行为是未指定的：存在一些非“良好定义”的执行情况。

从语言的角度来看，这意味着你的“主线程”可能看到也可能不会看到flag状态的变化。实际行为确实可能取决于你的硬件平台（包括CPU类型、核心数量、RAM大小），特定的JRE版本和构建，或者实际上...任何因素。

尝试理解为什么编写了“不正确”的代码在你调整它时行为会发生变化是没有意义的。你不应该写出这样的代码……即使你认为你知道“幕后”发生了什么。未指定的“幕后”细节可能会改变，在不同的机器上可能不同，等等。

那么实际上发生了什么呢？

很难确定，但我怀疑print调用本身也在做一些同步操作，而这恰好导致了内存缓存被刷新¹。

但你不能依赖这一点。相关的类并未规定有此效果。这是一个幸运的实现细节。

注意：由于flag没有声明为volatile，对于JIT编译器来说，检测到没有“先行发生”关系并随后生成一次从RAM读取flag并放入寄存器的代码将是一种合理的优化²。如果这样做，print("");的技巧将不会产生任何影响。

^{1 - 假设涉及内存缓存。还有其他可能的“机制”在起作用；例如，寄存器的使用。

2 - 合法意味着它不违反JMM的可见性保证。这些保证仅适用于“良好定义”的执行！}

Mark Baker · Answer

Stephen C 和 Solomon Slow 的两个回答都是正确的。

使用 `AtomicBoolean` 而非 `volatile`

针对你遇到的问题，我更倾向于使用 Atomic… 类来解决。使用这些类能清晰地提醒读者我们正在跨线程保护访问。

若要保存布尔值，请使用 AtomicBoolean。

将你的 Boolean 变量改为 AtomicBoolean 后，就不需要 volatile 关键字了。

我不太了解 Kotlin 的语法，但我会尝试修改你的代码。这里我们在无需使用 volatile 的情况下实现了线程安全。

class VolatileExample3 {

    var flag = AtomicBoolean(false)

    var a = 0

    fun write() {
        a = 1
        Thread.sleep(10)
        flag.set(true)
    }

    companion object {
        @JvmStatic
        fun test() {
            val example = VolatileExample3()
            val th = Thread {
                example.write()
            }
            th.start()
            while (!example.flag.get()) {}
            println("a = ${example.a}")
        }
    }
}

当然，你的代码还存在另一个并发问题。在执行 while 语句与 println 之间存在时间差，在这段时间内标志位可能被改变。但这似乎超出了你的问题范围。