volatile 能到这份上，也就差不多了

发表于 3年以前 | 总阅读数：282 次

写volatile的文章非常多，本人也看过许多相关文章，但始终感觉有哪里不太明白，但又说不上来说为什么。可能是过于追求底层实现原理，老想问一个为什么吧。

而写这篇文章的目的很简单，就是突然之间明白了volatile为什么要这样设计了。好东西当然要拿出来分享了，于是就有了这篇文章。

我们就从硬件到软件，再到具体的案例来聊聊volatile的底层原理，文章比较长，可收藏之后阅读。

CPU缓存的出现

最初的CPU是没有缓存区的，CPU直接读写内存。但这就存在一个问题，CPU的运行效率与读写内存的效率差距百倍以上。总不能CPU执行1个写操作耗时1个时钟周期，然后再等待内存执行一百多个时钟周期吧。

于是在CPU和内存之间添加了缓存（CPU缓存：Cache Memory），它是位于CPU和内存之间的临时存储器。这就像当Mysql出现瓶颈时，我们会考虑通过缓存数据来提升性能一样。总之，CPU缓存的出现就是为了解决CPU和内存之间处理速度不匹配的问题而诞生的。

这时，我们有一个粗略的图：

CPU-CPU缓存-内存

但考虑到进一步优化数据的调度，CPU缓存又分为一级缓存、二级缓存、三级缓存等。它们主要用于优化数据的吞吐和暂存，提高执行效率。

目前主流CPU通常采用三层缓存：

一级缓存（L1 Cache）：主要用于缓存指令（L1P）和缓存数据（L1D），指令和数据是分开存储的。一级缓存属于核心独享，比如4核电脑，则有4个L1。
二级缓存（L2 Cache）：二级缓存的指令和数据是共享的，二级缓存的容量会直接影响CPU的性能，越大越好。二级缓存同样属于核心独享，4核心电脑，则有4个L2。
三级缓存（L3 Cache）：作用是进一步降低内存的延迟，同时提升海量数据计算的性能。三级缓存属于核心共享的，因此只有1个。

经过上述细分，可以将上图进一步细化：

CPU三级缓存

这里再补充一个概念：缓存行（Cache-line），它是CPU缓存存储数据的最小单位，后面会用到。上面的CPU缓存，也称作高速缓存。

引入缓存之后，每个CPU的处理过程为：先将计算所需数据缓存在高速缓存中，当CPU进行计算时，直接从高速缓存读取数据，计算完成再写入缓存中。当整个运算过程完成之后，再把缓存中的数据同步到主内存中。

如果是单核CPU这样处理没有什么问题。但在多核系统中，每个CPU都可能将同一份数据缓存到自己的高速缓存中，这就出现了缓存数据一致性问题了。

CPU层提供了两种解决方案：总线锁和缓存一致性。

总线锁

前端总线(也叫CPU总线)是所有CPU与芯片组连接的主干道，负责CPU与外界所有部件的通信，包括高速缓存、内存、北桥，其控制总线向各个部件发送控制信号、通过地址总线发送地址信号指定其要访问的部件、通过数据总线双向传输。

比如CPU1要操作共享内存数据时，先在总线上发出一个LOCK#信号，其他处理器就不能操作缓存了该共享变量内存地址的缓存，也就是阻塞了其他CPU，使该处理器可以独享此共享内存。

很显然，这样的做法代价十分昂贵，于是为了降低锁粒度，CPU引入了缓存锁。

缓存一致性协议

缓存一致性：缓存一致性机制整体来说，就是当某块CPU对缓存中的数据进行操作了之后，会通知其他CPU放弃储存在它们内部的缓存，或者从主内存中重新读取。

缓存锁的核心机制就是基于缓存一致性协议来实现的，即一个处理器的缓存回写到内存会导致其他处理器的缓存无效，IA-32处理器和Intel 64处理器使用MESI实现缓存一致性协议。

缓存一致性是一个协议，不同处理器的具体实现会有所不同，MESI是一种比较常见的缓存一致性协议实现。

MESI协议

MESI协议是以缓存行的几个状态来命名的（全名是Modified、Exclusive、Share or Invalid）。该协议要求在每个缓存行上维护两个状态位，每个数据单位可能处于M、E、S和I这四种状态之一，各种状态含义如下：

M（Modified）：被修改的。该状态的数据，只在本CPU缓存中存在，其他CPU没有。同时，对于内存中的值来说，是已经被修改了，但还没更新到内存中去。也就是说缓存中的数据和内存中的数据不一致。
E（Exclusive）：独占的。该状态的数据，只在本CPU缓存中存在，且并没有被修改，与内存数据一致。
S（Share）：共享的。该状态的数据，在多个CPU缓存中同时存在，且与内存数据一致。
I（Invalid）：无效的。本CPU中的这份缓存数据已经失效。

其中上述状态随着不同CPU的操作还会进行不停的变更：

一个处于M状态的缓存行，必须时刻监听所有试图读取该缓存行对应的主存地址的操作，如果监听到，则必须在此操作执行前把其缓存行中的数据写回CPU。
一个处于S状态的缓存行，必须时刻监听使该缓存行无效或者独享该缓存行的请求，如果监听到，则必须把其缓存行状态设置为I。
一个处于E状态的缓存行，必须时刻监听其他试图读取该缓存行对应的主存地址的操作，如果监听到，则必须把其缓存行状态设置为S。

对于MESI协议，从CPU读写角度来说会遵循以下原则：

CPU读数据：当CPU需要读取数据时，如果其缓存行的状态是I的，则需要从内存中读取，并把自己状态变成S，如果不是I，则可以直接读取缓存中的值，但在此之前，必须要等待其他CPU的监听结果，如其他CPU也有该数据的缓存且状态是M，则需要等待其把缓存更新到内存之后，再读取。

CPU写数据：当CPU需要写数据时，只有在其缓存行是M或者E的时候才能执行，否则需要发出特殊的RFO指令(Read Or Ownership，这是一种总线事务)，通知其他CPU设置缓存无效(I)，这种情况下性能开销是相对较大的。在写入完成后，修改其缓存状态为M。

当引入总线锁或缓存一致性协议之后，CPU、缓存、内存的结构变为下图：

CPU-缓存-总线-内存

MESI协议带来的问题

在上述MESI协议的交互过程中，我们已经可以看到在各个CPU之间存在大量的消息传递（监听处理）。而缓存的一致性消息传递是需要时间的，这就使得切换时会产生延迟。一个CPU对缓存中数据的改变，可能需要获得其他CPU的回执之后才能继续进行，在这期间处于阻塞状态。

Store Bufferes

等待确认的过程会阻塞处理器，降低处理器的性能。而且这个等待远远比一个指令的执行时间长的多。为了避免资源浪费，CPU又引入了存储缓存（Store Bufferes）。

基于存储缓存，CPU将要写入内存数据先写入Store Bufferes中，同时发送消息，然后就可以继续处理其他指令了。当收到所有其他CPU的失效确认（Invalidate Acknowledge）时，数据才会最终被提交。

举例说明一下Store Bufferes的执行流程：比如将内存中共享变量a的值由1修改为66。

第一步，CPU-0把a=66写入Store Bufferes中，然后发送Invalid消息给其他CPU，无需等待其他CPU相应，便可继续执行其他指令了。

store bufferes

第二步，当CPU-0收到其他所有CPU对Invalid通知的相应之后，再把Store Bufferes中的共享变量同步到缓存和主内存中。

store Bufferes

Store Forward（存储转发）

Store Bufferes的引入提升了CPU的利用效率，但又带来了新的问题。在上述第一步中，Store Bufferes中的数据还未同步到CPU-0自己的缓存中，如果此时CPU-0需要读取该变量a，缓存中的数据并不是最新的，所以CPU需要先读取Store Bufferes中是否有值。如果有则直接读取，如果没有再到自己缓存中读取，这就是所谓的”Store Forward“。

失效队列

CPU将数据写入Store Bufferes的同时还会发消息给其他CPU，由于Store Bufferes空间较小，且其他CPU可能正在处理其他事情，没办法及时回复，这个消息就会陷入等待。

为了避免接收消息的CPU无法及时处理Invalid失效数据的消息，造成CPU指令等待，就在接收CPU中添加了一个异步消息队列。消息发送方将数据失效消息发送到这个队列中，接收CPU返回已接收，发送方CPU就可以继续执行后续操作了。而接收方CPU再慢慢处理”失效队列“中的消息。

内存屏障

CPU经过上述的一系列优化，既保证了效率又确保了缓存的一致性，大多数情况下也是可以接受CPU基于Store Bufferes和失效队列异步处理的短暂延迟的。

但在多线程的极端情况下，还是会产生缓存数据不一致的情况的。比如上述实例中，CPU-0修改数据，发消息给其他CPU，其他CPU消息队列接收成功并返回。这时CPU-1正忙着处理其他业务，没来得及处理消息队列，而CPU-1处理的业务中恰好又用到了变量a，此时就会造成读取到的a值为旧值。

这种因为CPU缓存优化导致后面的指令无法感知到前面指令的执行结果，看起来就像指令之间的执行顺序错乱了一样，对于这种现象我们俗称“CPU乱序执行”。

乱序执行是导致多线程下程序Bug的原因，解决方案很简单：禁用CPU缓存优化。但大多数情况下的数据并不存在共享问题，直接禁用会导致整体性能下降，得不偿失。于是就提供了针对多线程共享场景的解决机制：内存屏障机制。

使用内存屏障后，写入数据时会保证所有指令都执行完毕，这样就能保证修改过的数据能够即时暴露给其他CPU。而读取数据时，能够保证所有“失效队列”消息都消费完毕。然后，CPU根据Invalid消息判断自己缓存状态，正确读写数据。

CPU层面的内存屏障

CPU层面提供了三类内存屏障：

写屏障（Store Memory Barrier）：告诉处理器在写屏障之前将所有存储在存储缓存(store bufferes)中的数据同步到主内存。也就是说当看到Store Barrier指令，就必须把该指令之前所有写入指令执行完毕才能继续往下执行。
读屏障(Load Memory Barrier)：处理器在读屏障之后的读操作，都在读屏障之后执行。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据。
全屏障(Full Memory Barrier)：兼具写屏障和读屏障的功能。确保屏障前的内存读写操作的结果提交到内存之后，再执行屏障后的读写操作。

下面通过一段伪代码来进行说明：

public class Demo {
    int value;
    boolean isFinish;

    void cpu0(){
        value = 10; // S->I状态，将value写入store bufferes，通知其他CPU value缓存失效
        storeMemoryBarrier(); // 插入写屏障，将value=10强制写入主内存
        isFinish = true; // E状态
    }

    void cpu1(){
        if (isFinish){ // true
            loadMemoryBarrier(); //插入读屏障，强制cpu1从主内存中获取最新数据
            System.out.println(value == 10); // true
        }
    }

    void storeMemoryBarrier(){//写屏障
    }
    void loadMemoryBarrier(){//读屏障
    }
}

上述实例中通过内存屏障防止了指令重排，能够得到预期的结果。

总之，内存屏障的作用可以通过防止CPU乱序执行来保证共享数据在多线程下的可见性。那么，在JVM中是如何解决该问题的呢？也就是编程人员如何进行控制呢？这就涉及到我们要讲的volatile关键字了。

Java内存模型

内存屏障解决了CPU缓存优化导致的指令执行的顺序性和可见性问题，但不同的硬件系统提供的“内存屏障”指令又有所不同，作为开发人员也没必要熟悉所有的内存屏障指令。而Java将不同的内存屏障指令进行了统一封装，开发人员只需关注程序逻辑开发和内存屏障规范即可。

这套封装解决方案的模型就是我们常说的Java内存模型（Java Memory Model），简称JMM。JMM最核心的价值便在于解决可见性和有序性，它是对硬件模型的抽象，定义了共享内存中多线程程序读写操作的行为规范。

这套规范通过限定对内存的读写操作从而保证指令的正确性，解决了CPU多级缓存、处理器优化、指令重排序导致的内存访问问题，保证了并发场景下的可见性。

本质上，JMM是把硬件底层的问题抽象到了JVM层面，屏蔽了各个平台的硬件差异，然后再基于CPU层面提供的内存屏障指令以及限制编译器的重排序来解决并发问题的。

JMM抽象模型结构

JMM抽象模型中将内存分为主内存和工作内存：

主内存：所有线程共享，存储实例对象、静态字段、数组对象等存储在堆中的变量。
工作内存：每个线程独享，线程对变量的所有操作都必须在工作内存中进行。

线程是CPU调度的最小单位，线程之间的共享变量值的传递都必须通过主内存来完成。

JMM抽象模型结构图如下：

JMM抽象模型

JMM内存模型简单概述就是：

所有变量存储在主内存；
每条线程拥有自己的工作内存，其中保存了主内存中线程使用到的变量的副本；
线程不能直接读写主内存中的变量，所有操作均在工作内存中完成；

如果线程A需要与线程B进行通信，则线程A先把本地缓存中的数据更新到主内存，再由线程B从主内存中进行获取。JMM通过控制主内存与每个线程的本地内存之间的交互，来为Java程序提供内存可见性保证。

编译器指令重排

除了硬件层面的指令重排，Java编译器为了提升性能，也会对指令进行重排。Java规范规定JVM线程内部维持顺序化语义，即只要程序的最终结果与它顺序化执行的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。

JVM能根据处理器特性（CPU多级缓存系统、多核处理器等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。

从源码到最终执行示例图：

指令重排序

其中2和3属于CPU执行阶段的重排序，1属于编译器阶段的重排序。编译器会遵守happens-before规则和as-if-serial语义的前提下进行指令重排。

happens-before规则：如果A happens-before B，且B happens-before C，则需要保证A happens-before C。

as-if-serial语义：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器、Runtime和处理器都必须遵守as-if-serial语义。

对于处理器重排序，JMM要求Java编译器在生成指令序列时，插入特定类型的内存屏障指令，来禁止特定类型的处理重排序。

JMM的内存屏障

上面了解了CPU的内存屏障分类，在JMM中把内存屏障分为四类：

LoadLoad Barriers：示例，Load1；LoadLoad；Load2，确保Load1数据的装载先于Load2及所有后续指令的装载；
StoreStore Barriers：示例，Store1；StoreStore；Store2，确保Store1数据对其他处理器可见（刷新到内存）先于Store2及所有后续存储指令的存储；
LoadStore Barriers：示例，Load1；LoadStore；Store2，确保Load1数据装载先于Store2及所有后续存储指令刷新到内存；
StoreLoad Barriers：示例，Store1；StoreLoad；Load2，确保Store1数据对其他处理器变得可见（刷新到内存）先于Load2及所有后续装载指令的装载。StoreLoad Barriers会使该屏障之前的所有内存访问指令（存储和装载指令）完成之后，才执行该屏障之后的内存访问指令。

其中，StoreLoad Barriers同时具有前3个的屏障的效果，但性能开销很大。

为了实现volatile内存语义，JMM会分别限制这两种类型的重排序类型。下图是JMM针对编译器制定的volatile重排序规则表。

JMM重排序

从图中可以得出一个基本规则：

当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保volatile写之前的操作不会被编译器重排序到volatile写之后。
当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。
当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能。为此，JMM采取保守策略。下面是基于保守策略的JMM内存屏障插入策略：

在每个volatile写操作的前面插入一个StoreStore屏障。
在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的后面插入一个LoadLoad屏障。
在每个volatile读操作的后面插入一个LoadStore屏障。

保守策略下volatile写插入内存屏障后生成的指令序列示意图：

volatile写屏障

保守策略下volatile读插入内存屏障后生成的指令序列示意图：

volatile读内存屏障

JMM对volatile的特殊规则定义

JVM内存指令与volatile相关的操作有：

read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用；
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中；
use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作；
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作；
store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作；
write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中；

在对volatile修饰的变量进行操作时，需满足以下规则：

规则1：线程对变量执行的前一个动作是load时才能执行use，反之只有后一个动作是use时才能执行load。线程对变量的read，load，use动作关联，必须连续一起出现。这保证了线程每次使用变量时都需要从主存拿到最新的值，保证了其他线程修改的变量本线程能看到。
规则2：线程对变量执行的前一个动作是assign时才能执行store，反之只有后一个动作是store时才能执行assign。线程对变量的assign，store，write动作关联，必须连续一起出现。这保证了线程每次修改变量后都会立即同步回主内存，保证了本线程修改的变量其他线程能看到。
规则3：有线程T，变量V、变量W。假设动作A是T对V的use或assign动作，P是根据规则2、3与A关联的read或write动作；动作B是T对W的use或assign动作，Q是根据规则2、3与B关联的read或write动作。如果A先与B，那么P先与Q。这保证了volatile修饰的变量不会被指令重排序优化，代码的执行顺序与程序的顺序相同。

volatile实例及分析

通过上面的分析关于volatile关键词的来源，以及被它修饰的变量的可见性和有序性都从理论层面讲解清楚了。下面看一个可见性的实例。

示例代码如下：

public class VolatileTest {

 private boolean initFlag = false;

 public static void main(String[] args) throws InterruptedException {
  VolatileTest sample = new VolatileTest();
  Thread threadA = new Thread(sample::refresh, "threadA");

  Thread threadB = new Thread(sample::load, "threadB");

  threadB.start();
  Thread.sleep(2000);
  threadA.start();
 }

 public void refresh() {
  this.initFlag = true;
  System.out.println("线程：" + Thread.currentThread().getName() + ":修改共享变量initFlag");
 }

 public void load() {
  int i = 0;
  while (!initFlag) {
  }
  System.out.println("线程：" + Thread.currentThread().getName() + "当前线程嗅探到initFlag的状态的改变" + i);
 }
}

根据上面的理论知识，先猜测一下线程先后打印出的内容是什么？先打印”线程threadA修改共享变量initFlag“，然后打印”线程threadB当前线程嗅探到initFlag的状态的改变0“？

当真正执行程序时，会发现整个线程阻塞在while循环处，并未打印出第2条内容。此时JMM操作如下图：

thread-without-volatile

虽然线程A中将initFlag改为了true并且最终会同步回主内存，但是线程B中循环读取的initFlag一直都是从工作内存读取的，所以会一直进行死循环无法退出。

当对变量initFlag添加了volatile修饰之后：

public class VolatileTest {

 private volatile boolean initFlag = false;
 //...
}

JMM操作如下图：

thread-with-volatile

添加了volatile修饰之后，两句日志都会被打印出来。这是因为添加volatile关键字后，就会有lock指令，使用缓存一致性协议，线程B中会一直嗅探initFlag是否被改变，线程A修改initFlag后会立即同步回主内存，同时通知线程B将缓存行状态改为I（无效状态），重新从主内存读取。

volatile无法保证原子性

volatile虽然保证了共享变量的可见性和有序性，但并不能够保证原子性。

以常见的自增操作（count++）为例来进行说明，通常自增操作底层是分三步的：

第一步：获取变量count；
第二步：count加1；
第三步：回写count；

我们来分析一下在这个过程中会有的线程安全问题：

第一步，线程A和B同时获得count的初始值，这一步没什么问题；

第二步，线程A自增count并回写，但线程B此时也已经拿到count，不会再去拿线程A回写的值，因此对原始值进行自增并回写，这就导致了线程安全的问题。有人可能要问了，线程A自增之后不是应该通知其他CPU缓存失效吗，并重新load吗？我们要知道，重新获取的前提操作是读，在线程A回写时，线程B已经拿到了count的值，并不存在再次读的场景。也就是说，线程B的缓存行的确会失效，但线程B中count值已经运行在加法指令中，不存在需要再次从缓存行读的场景。

volatile关键字只保证可见性，所以在以下情况中，需要使用锁来保证原子性：

运算结果依赖变量的当前值，并且有不止一个线程在修改变量的值。
变量需要与其他状态变量共同参与不变约束

所以，想要使用volatile变量提供理想的线程安全，必须同时满足两个条件：

对变量的写操作不依赖于当前值。
该变量没有包含在具有其他变量的不变式中。

也就是说被修饰的变量值独立于任何程序的状态，包括变量的当前状态。

volatile适用场景

状态标志

使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。

volatile boolean shutdownRequested;

...

public void shutdown() { 
    shutdownRequested = true; 
}

public void doWork() { 
    while (!shutdownRequested) { 
        // do stuff
    }
}

线程1执行doWork()的过程中，线程2可能调用了shutdown，所以boolean变量必须是volatile。

这种状态标记的一个公共特性是：通常只有一种状态转换；shutdownRequested 标志从false 转换为true，然后程序停止。这种模式可以扩展到来回转换的状态标志，但是只有在转换周期不被察觉的情况下才能扩展（从false 到true，再转换到false）。此外，还需要某些原子状态转换机制，例如原子变量。

一次性安全发布

在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。

这种场景在著名的双重检查锁定（double-checked-locking）中会出现：

//注意volatile！
private volatile static Singleton instace;   

public static Singleton getInstance(){   
    //第一次null检查     
    if(instance == null){            
        synchronized(Singleton.class) {    //1     
            //第二次null检查       
            if(instance == null){          //2  
                instance = new Singleton();//3  
            }  
        }           
    }  
    return instance;        
}

其中第3步中实例化Singleton分多步执行（分配内存空间、初始化对象、将对象指向分配的内存空间），某些编译器为了性能原因，会将第二步和第三步进行重排序（分配内存空间、将对象指向分配的内存空间、初始化对象）。这样，某个线程可能会获得一个未完全初始化的实例。

独立观察（independent observation）

场景：定期 “发布” 观察结果供程序内部使用。比如，传感器感知温度，一个线程每隔几秒读取一次传感器，并更新当前的volatile修饰变量。其他线程可以读取这个变量，随时看到最新温度。

另一种场景就是应用程序搜集统计信息。比如记录最后一次登录的用户名，反复使用lastUser引用来发布值，以供其他程序使用。

public class UserManager {
    public volatile String lastUser; //发布的信息

    public boolean authenticate(String user, String password) {
        boolean valid = passwordIsValid(user, password);
        if (valid) {
            User u = new User();
            activeUsers.add(u);
            lastUser = user;
        }
        return valid;
    }
}

“volatile bean” 模式

volatile bean 模式的基本原理是：很多框架为易变数据的持有者（例如 HttpSession）提供了容器，但是放入这些容器中的对象必须是线程安全的。在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通——即不包含约束。

@ThreadSafe
public class Person {
    private volatile String firstName;
    private volatile String lastName;
    private volatile int age;

    public String getFirstName() { return firstName; }
    public String getLastName() { return lastName; }
    public int getAge() { return age; }

    public void setFirstName(String firstName) { 
        this.firstName = firstName;
    }

    public void setLastName(String lastName) { 
        this.lastName = lastName;
    }

    public void setAge(int age) { 
        this.age = age;
    }
}

开销较低的“读－写锁”策略

如果读操作远远超过写操作，可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。

如下线程安全的计数器代码，使用 synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销。

@ThreadSafe
public class CheesyCounter {
    // Employs the cheap read-write lock trick
    // All mutative operations MUST be done with the 'this' lock held
    @GuardedBy("this") private volatile int value;

    //读操作，没有synchronized，提高性能
    public int getValue() { 
        return value; 
    } 

    //写操作，必须synchronized。因为x++不是原子操作
    public synchronized int increment() {
        return value++;
    }

使用锁进行有变化的操作，使用volatile进行只读操作。volatile允许多个线程同时执行读操作。