2020版Java并发和多线程教程（十三）：Java volatile关键字（变量可见性，可见性规则，指令重排序，Happens-Before规则）
翻译：GentlemanTsao，2020-5-20 系列专栏：java并发和多线程教程2020版
文章目录
- 变量可见性问题
- Java volatile可见性规则
- volatile可见性完整规则
- 指令重排序带来的难题
- Java volatile的Happens-Before规则
- volatile不是万金油
- volatile在什么时候有用
- volatile的性能斟酌
Java volatile关键字用于将Java变量标记为“存储在主内存中”。更确切地说，这意味着：volatile变量每次都将从计算机的主存储器读取，而不是CPU缓存中；volatile变量每次都将写入主存储器，而不仅仅是CPU缓存。
实际上，从Java5开始，volatile关键字保证的不仅仅是volatile变量从主内存读取和写入。我将在下面的章节中解释这一点。
变量可见性问题
Java volatile关键字保证了跨线程变量更改的可见性。这听起来可能有点抽象，所以让我详细说明一下。
在多线程应用程序中，线程对非易失性变量进行操作，出于性能原因，每个线程都可以在处理变量时将变量从主内存复制到CPU缓存中。如果计算机包含多个CPU，则每个线程可能在不同的CPU上运行。这意味着，每个线程可以将变量复制到不同CPU的CPU缓存中。下面举例说明：
对于非易失性变量，无法保证Java虚拟机（JVM）何时将数据从主内存读取到CPU缓存，何时将数据从CPU缓存写入主内存。这可能会导致一些问题，我将在下面的章节中解释。
假设两个或多个线程访问一个共享对象，该对象包含了一个counter变量声明如下：
public class SharedObject {
public int counter = 0;
}想象一下，只有线程1递增counter变量，但线程1和线程2都可能不时地读取counter变量。
如果计数器变量未声明为volatile，则无法保证counter变量的值何时从CPU缓存写入主内存。这意味着，CPU缓存中的counter变量值可能与主内存中的不同。这种情况如下所示：
线程没有看到一个变量的最新值，因为它还没有被另一个线程写回主内存，这个问题被称为“可见性”问题。一个线程的更新对其他线程不可见。
Java volatile可见性规则
Java volatile关键字旨在解决变量可见性问题。通过声明counter变量volatile，所有对counter变量的写入都将立即写回主内存。此外，counter变量的所有读取都将直接从主内存中读取。
volatile声明的counter变量像下面这样：
public class SharedObject {
public volatile int counter = 0;
}因此，声明变量volatile可以保证该变量的写入对其他线程的可见性。
在上面给出的场景中，一个线程（T1）修改counter，另一个线程（T2）读取counter（但从不修改），声明counter变量volatile足以保证counter变量的写入对T2可见。
但是，如果T1和T2都在递增counter变量，那么声明counter变量为volatile是不够的。接下来再讨论。
volatile可见性完整规则
实际上，Java volatile的可见性规则超出了volatile变量本身。可见性规则如下：
- 如果线程A写入volatile变量，而线程B随后读取相同的volatile变量，那么线程A在写入volatile变量之前可见的所有变量，在线程B读取volatile变量之后也将可见。
- 如果线程A读取volatile变量，那么线程A在读取volatile变量时可见的所有变量也将从主内存中重新读取。
让我用一个代码示例来说明这一点：
public class MyClass {
private int years;
private int months
private volatile int days;
public void update(int years, int months, int days){
this.years = years;
this.months = months;
this.days = days;
}
}udpate（）方法写入三个变量，其中只有days是volatile。
volatile可见性完整规则意味着，当days写入一个值时，线程可见的所有变量也将写入主内存。这意味着，当days写入一个值时，years和months的值也被写入主内存。
你可以这样做来读取years，months，days 的值:
public class MyClass {
private int years;
private int months
private volatile int days;
public int totalDays() {
int total = this.days;
total += months * 30;
total += years * 365;
return total;
}
public void update(int years, int months, int days){
this.years = years;
this.months = months;
this.days = days;
}
}注意totalDays（）方法首先将days的值读入total变量。当读取days的值时，months和years的值也会读入主存储器。因此，按上述读取顺序，可以确保读到days、months和years的最新值。
指令重排序带来的难题
出于性能原因，只要指令的语义保持不变，Java虚拟机和CPU就可以对程序中的指令重新排序。例如，看看以下指令：
int a = 1;
int b = 2;
a++;
b++;这些指令可以重新排序为以下顺序，而不会丧失程序的语义：
int a = 1;
a++;
int b = 2;
b++;然而，当其中一个变量是volatile变量时，指令重新排序是一个难题。让我们看看本篇前面示例中的MyClass类：
public class MyClass {
private int years;
private int months
private volatile int days;
public void update(int years, int months, int days){
this.years = years;
this.months = months;
this.days = days;
}
}update（）方法将值写入days后，新写入的years和months值也将写入主内存。但是，如果Java虚拟机重新排列了指令呢？比如像这样：
public void update(int years, int months, int days){
this.days = days;
this.months = months;
this.years = years;
}当days变量被修改时，months和years的值仍会写入主内存，但这次是在新值写入months和years之前发生的。因此，其他线程无法正确地看到新值。重新排序的指令的语义发生了变化。
我们将在下一节中看到，Java有一个方案可以解决这个问题。
Java volatile的Happens-Before规则
为了解决指令重新排序的难题，除了可见性规则之外，Java volatile关键字还提供“happens before”规则。“happens before”规则确保了：
- 如果读/写最初发生在对volatile变量的写入之前，则不能将对其他变量的读/写重新排序为在对volatile变量的写入之后发生。
- 在写入volatile变量之前的读/写操作保证在写入volatile变量之前发生。请注意，仍然有可能出现这种情况，例如，volatile的写操作之后的其他变量的读/写，重排序为在volatile的写操作之前。反之则不行。允许从后到前，但不允许从前到后。
- 如果对其他变量的读取/写入最初发生在读取volatile变量之后，则不能将该读取和写入重新排序为在读取volatile变量之前发生。注意，在volatile变量的读取之前发生的其他变量的读取可能会被重新排序为在volatile变量的读取之后发生。反之则不行。允许从前到后，但不允许从后到前。
（
译者注：
作者对H-B规则描述的虽然正确，但不够清晰。H-B规则是为了解决指令重排序与可见性规则的冲突。所以，将H-B规则和可见性规则对照起来，就很容易理解了。
首先，可见性规则解决了缓存一致性问题。解决方法可理解为“两个刷新”：
写volatile时将所有可见变量从缓存刷新到内存，简记为“写刷新”；
读volatile时将所有可见变量从内存刷新到缓存，简记为“读刷新”。
通过“两个刷新”，保证了在读/写volatile时，变量在内存和缓存中是一致。
但是，由于指令重排序的存在，刷新的动作会导致语义变化。例如对于写刷新，代码预期的是变量修改后刷新到内存，结果由于指令重排序变成了刷新到内存后再修改变量。错的很离谱。
于是，H-B规则对指令重排作了限制，本质上可以理解为，指令重排不能影响刷新的结果。
建议不必记具体规则，但应理解为什么要这么做。
）
上述的happens-before规则确保了volatile关键字的可见性规则能够生效。
volatile不是万金油
即使volatile关键字保证所有volatile变量的读取都直接从内存中读取，并且所有volatile变量的写入都直接写入内存，但在某些情况下，仅声明变量为volatile仍然是不够的。
在前面阐述的只有线程1写入共享counter变量的情况下，声明counter变量为volatile足以确保线程2始终看到最新的写入值。
事实上，如果写入变量的新值不依赖于它的前值，甚至可以有多个线程写入共享的volatile变量，并且主内存中存储的值仍然是正确的。换句话说，如果一个线程向共享的volatile变量写入一个值，它不需要首先读取它的值来计算它的下一个值。
只要线程需要首先读取volatile变量的值，并基于该值生成新值赋给共享的volatile变量，volatile变量就不再足以保证正确的可见性。读取volatile变量和写入新值之间的短暂时间间隔，造成了一个竞态条件，多个线程可能读取volatile变量的同一个值，为该变量生成一个新值，并且在将该值写入主内存时覆盖彼此的值。
多个线程递增同一个计数器的情况正是这样一种情况，即volatile变量不够用了。以下各节将更详细地解释这个案例。
假设线程1将一个值为0的共享counter变量读入其CPU缓存，将其递增为1，但没有将更改后的值写回主内存。然后，线程2可以将相同的counter变量从主内存（变量值仍然为0）读取到自己的CPU缓存中。然后线程2也可以将counter增加到1，并且也没有将其写回主内存。这种情况如下图所示：
线程1和线程2现在几乎不同步。共享counter变量的实际值应该是2，但每个线程的CPU缓存中该变量的值是1，在主内存中该值仍然为0。真是一团糟！即使线程最终将共享counter变量的值写回主内存，该值也会出错。
volatile在什么时候有用
如前所述，如果两个线程都在读写一个共享变量，那么使用volatile关键字是不够的。在这种情况下，需要使用synchronized来保证变量的读写是原子的。读取或写入volatile变量不会阻塞线程的读取或写入。为此，必须在临界区周围使用synchronized关键字。
作为同步块的替代，还可以使用java.util.concurrent包中的原子数据类型。例如，AtomicLong或AtomicReference或其他类型。
如果只有一个线程读取和写入volatile变量的值，而其他线程只读取该变量，那么可以保证读取线程看到volatile变量写入的最新值。如果不标记变量为volatile，就无法保证这一点。
volatile关键字可以保证在32位和64个变量上有效。
volatile的性能斟酌
读写volatile变量会导致变量从内存读写。从内存读写比访问CPU缓存的开销更大。访问volatile变量还会阻止指令重新排序，这是一种正常的性能增强技术。因此，只有在真正需要保证变量可见性时，才应该使用volatile变量。
下一篇：
2020版Java并发和多线程教程（十四）：Java ThreadLocal
系列专栏：Java并发和多线程教程2020版