一、上下文切换
1、概念
单核处理器支持多线程程序，其本质是 CPU 利用时间片轮转的方式为不同的线程分配系统资源，从而实现并发的效果（注意：这不是并行）。
时间片是 CPU 分配给各个线程的时间，因为时间片非常短，所以 CPU 通过不同地切换线程执行，达到近似于多个线程同时执行的效果，时间片一般是几十毫秒。
CPU 通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换之前会保存上一个任务的状态，以便下次切换回这个任务时，可以再加载这个任务的状态。
任务从保存到再加载的过程就是一次上下文切换。
2、并发和串行
当数据规模较小时，并发执行和串行执行相差不大，甚至有时候会比串行要慢，这是因为线程有创建和上下文切换的消耗。
度量上下文切换消耗的工具
Lmbench3- Linux 的
vmstat命令
3、减少上下文切换
减少上下文切换的方法有无锁并发编程、CAS 算法、使用最少线程和使用协程。
（1）无锁并发编程：多线程竞争锁时，会引起上下文切换，所以多线程处理数据时，可以用一些方法来避免使用锁，如将数据的 ID 按照 Hash 算法取模分段，不同的线程处理不同段的数据；
（2）CAS 算法：Java 的 Atomic 包使用 CAS 算法来更新数据，而不需要加锁；
（3）使用最少线程：避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态；
（4）协程：在单线程中实现多任务的调度，并在单线程里维持多个任务间的切换。
使用 jstack
在 Linux 系统中可以使用相关命令查询进程的 PID，然后利用 Java 提供的工具 jstack 来 dump 线程信息，看看 Java 进程中的线程状况（首先需要了解线程状态）。
4、死锁
锁是非常好用的工具，运用场景非常多，因为它使用起来非常简单，而且易于理解。但同时它也会带来一些困扰，那就是可能引起死锁，一旦产生死锁，就会造成系统功能不可用。
例如下面这段代码会引起死锁，线程 t1 和线程 t2 互相等待对方释放锁：
public class DeadLockDemo {
private static final String A = "A";
private static final String B = "B";
public static void main(String[] args) {
new DeadLockDemo().deadLock();
}
private void deadLock() {
Thread t1 = new Thread(() -> {
synchronized (A) {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (B) {
System.out.println("1");
}
}
});
Thread t2 = new Thread(() -> {
synchronized (B) {
synchronized (A) {
System.out.println("2");
}
}
});
t1.start();
t2.start();
}
}在实际应用中不会出现上述代码，但是在一些更加复杂的情况中，可能因为一些异常情况无法释放锁（死循环），或者拿到数据库锁后，释放锁的时候抛出了异常，没释放掉。
一旦出现死锁，业务是可以感知到的，表现为无法提供正常服务，那么只能通过 dump 线程查看到底是哪个线程出现了问题。
避免死锁的几个常见方法
（1）避免一个线程同时获取多个锁；
（2）避免一个线程在锁内同时占用多个资源，尽量保证每个锁只占用一个资源；
（3）尝试使用定时锁，使用 lock.tryLock(timeout) 来替代使用内部锁机制；
（4）对于数据库锁，加锁和解锁必须在一个数据库连接里，否则会出现解锁失败的情况。
二、Java 并发机制底层实现原理
Java 代码在编译后会变成 Java 字节码，字节码被类加载器加载到 JVM 里，JVM 执行字节码，最终需要转换为汇编指令在 CPU 上执行，Java 中使用的并发机制依赖于 JVM 的实现和 CPU 的指令。
1、volatile 的应用
在 Java 并发编程中，synchronized 和 volatile 扮演着重要的角色，volatile 是轻量级的 synchronized，它在多处理器开发中保证了共享变量的 “可见性”。可见性的意思是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。
如果 volatile 变量修饰符使用恰当的话，它比 synchronized 的使用和执行成本更低，因为它不会引起线程上下文的切换和调度。
volatile 的定义与实现原理
Java 语言规范第三版中对 volatile 的定义如下：Java 编程语言允许线程访问共享变量，为了确保共享变量能够被准确和一致地更新，线程应该确保通过排他锁单独获得这个变量。Java 语言提供了 volatile，在某些情况下比锁要更加方便。如果一个字段被声明成 volatile，Java 线程内存模型确保所有线程看到这个变量的值是一致的。
在了解 volatile 实现原理之前，先看一下和其实现原理和 CPU 相关的术语：
| 术语 | 英文 | 描述 |
|---|---|---|
| 内存屏障 | memory barriers | 是一组处理器命令，用于实现对内存操作的顺序限制 |
| 缓冲行 | cache line | 缓存中可以分配的最小存储单位。处理器填写缓存线时会加载整个缓存线，需要使用多个主内存读周期 |
| 原子操作 | atomic operations | 不可中断的一个或一系列操作 |
| 缓存行填充 | cache line fill | 当处理器识别到从内存中读取操作数是可缓存的，处理器读取整个缓存行到适当的缓存（L1、L2、L3的或所有） |
| 缓存命中 | cache hit | 如果进行高速缓存行填充操作的内存位置仍然是下次处理器访问的地址时，处理器从缓存中读取操作数，而不是从内存读取 |
| 写命中 | write hit | 当处理器将操作数写回到一个内存缓存的区域时，它首先会检查这个缓存的内存地址是否在缓存行中，如果存在一个有效的缓存行，则处理器将这个操作数写回到缓存，而不是写回到内存，这个操作被称为写命中 |
| 写缺失 | write misses the cache | 一个有效的缓存行被写入到不存在的内存区域 |
volatile 是如何来保证内存可见性的呢？
在 X86 处理器中下面的 Java 代码对一个 volatile 变量进行写操作：
instance = new Singleton();如果转成汇编代码，会发现多了一个 Lock 前缀的指令，这个指令在多核处理器中会引发两件事情：
（1）将当前处理器缓存行的数据写回到系统内存；
（2）这个写回内存的操作会使得在其他 CPU 里缓存了该内存地址的数据无效。
为了提高处理器速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存（L1、L2或其他）后再进行操作，但操作不知道何时会写到内存。
如果对声明了 volatile 变量进行写操作，JVM 就会向处理器发送一条 Lock 前缀的指令，将这个变量所在的缓存行的数据写回到系统内存。但是，就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题。所以，在多处理器下，为了保证各个处理器的缓存是一致的，就会实现 缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作时，会重新从系统内存中把数据读取到处理器缓存里。
下面看看 volatile 的两条实现原则：
（1）Lock 前缀指令会引起处理器缓存回写到内存。Lock 前缀指令导致在执行指令期间，声言处理器的 LOCK# 信号。在多处理器环境中，LOCK# 信号确保在声言该信号期间，处理器可以独占任何共享内存。但是，在最近的处理器中，LOCK# 信号一般不锁总线，而是锁缓存，毕竟锁总线的开销比较大。现在的某些处理器是如果访问的内存区域已经缓存在处理器内部，则不会声言 LOCK# 信号。相反，它会锁定这块内存区域的缓存并回写到内存，并使用 缓存一致性机制 来确保修改的原子性，此操作被称为 **”缓存锁定”**，缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据。
（2）一个处理器的缓存回写到内存会导致其他处理器的缓存无效。IA-32 处理器和 Intel 64 处理器使用 MESI(修改、独占、共享、无效) 控制协议去维护内部缓存和其他处理器缓存的一致性。在多核处理器系统中进行操作的时候，IA-32 和 Intel 64 处理器能嗅探其他处理器访问系统内存和它们的内部缓存。处理器使用嗅探技术保证它的内部缓存、系统内存和其他处理器的缓存的数据在总线上保持一致。
2、synchronized 的实现原理与应用
在多线程并发编程中 synchronized 一直是元老级的角色，很多人称它为重量级锁。但是，随着 Java SE1.6 对 synchronized 进行了各种优化之后，有些情况它就并不那么重了。
注：Java SE1.6 中为了减少获得锁和释放锁带来的性能消耗而引入了偏向锁和轻量级锁。
先看看利用 synchronized 实现同步的基础：Java 中的每一个对象都可以作为锁，具体表现为以下三种形式：
（1）对于同步方法，锁是当前实例对象；
（2）对于静态同步方法，锁是当前类的 Class 对象；
（3）对于同步方法块，锁是 synchronized 括号里配置的对象。
当一个线程试图访问同步代码块时，它首先必须得到锁，退出或抛出异常时必须释放锁。
那么锁到底存在哪里呢？锁里面会存储什么信息呢？
从 JVM 规范中可以看到 synchronized 在 JVM 里的实现原理，JVM 基于进入和退出 Monitor 对象来实现方法同步和代码块同步，但两者的实现细节不一样。
- 代码块同步是使用
monitorenter和monitorexit指令实现的； - 方法同步是使用另外一种方式实现的，细节在 JVM 规范里并没有详细说明。
monitorenter 指令是在编译后插入到同步代码块的开始位置，而 monitorexit 是插入到方法结束出和异常处，JVM 要保证每个 monitorenter 必须有对应的 monitorexit 与之配对。任何对象都有一个 monitor 与之关联，并且一个 monitor 被持有后，它将处于锁定状态。线程执行到 monitorenter 指令时，将会尝试获取对象所对应的 monitor 的所有权，即尝试获得对象的锁。
Java 对象头
synchronized 用的锁是存在 Java 对象头里的。如果对象是数组类型，则虚拟机用 3 个字宽（Word）存储对象头，如果对象是非数组类型，则用 2 个字宽存储对象头。在 32 位虚拟机中，1 字宽等于 4 字节，即 32 bit：
| 长度 | 内容 | 说明 |
|---|---|---|
| 32/64bit | Mark Word | 存储对象的 hashCode 或锁信息等等 |
| 32/64bit | Class Metadata Address | 存储到对象类型数据的指针 |
| 32/64bit | Array length | 数组的长度（如果当前对象是数组） |
Java 对象头里的 Mark Word 里默认存储对象的 HashCode、分代年龄和锁标记位。\
32 位 JVM中的 Mark Word
32 位 JVM 的 Mark Word 的默认存储结构如下表所示：
| 锁状态 | 25bit | 4bit | 1bit 表示是否是偏向锁 | 2bit 锁标志位 |
|---|---|---|---|---|
| 无锁状态 | 对象的 hashCode | 对象分代年龄 | 0 | 01 |
在运行期间，Mark Word 中存储的信息会随着锁标志位的变化而变化。Mark Word 可能变化为存储以下 4 种数据：
| 锁状态 | 25bit | 4bit | 1bit | 2bit | ||
|---|---|---|---|---|---|---|
| 23bit | 2bit | 是否是偏向锁 | 锁标志位 | |||
| 轻量级锁 | 指向栈中锁记录的指针 | 00 | ||||
| 重量级锁 | 指向互斥量（重量级锁）的指针 | 10 | ||||
| GC 标记 | 空 | 11 | ||||
| 偏向锁 | 线程ID | Epoch | 对象分代年龄 | 1 | 01 | |
64 位 JVM 中的 Mark Word
64 位虚拟机下，Mark Word 是 64 bit 大小的，存储结构如下表所示：
3、锁的升级和对比
JavaSE 1.6 为了减少获得锁和释放锁带来的性能消耗，引入了 “偏向锁” 和 “轻量级锁”，在 JavaSE 1.6 中，锁一共有 4 种状态，级别从低到高依次是：
（1）无锁状态；
（2）偏向锁状态；
（3）轻量级锁状态；
（4）重量级锁状态。
这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。
（1）偏向锁
据研究表明，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程 ID，以后该线程在进入和退出同步块时不需要进行 CAS 操作来加锁和释放锁，只需简单地测试一下对象头的 Mark Word 里是否存储着指向当前线程的偏向锁。
如果测试成功，表明线程已经获得了锁。如果测试失败，则需要再测试一下 Mark Word 中偏行锁的标识是否设置成 1（1 表示当前是偏向锁）：
- 如果没有设置，则使用 CAS 竞争锁；
- 如果设置了，则尝试使用 CAS 将对象头的偏向锁指向当前线程。
偏向锁的撤销
偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有正在执行的字节码）。它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着：
- 如果线程不处于活动状态，则将对象头设置成无锁状态；
- 如果线程仍然活着，持有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的
Mark Word要么重新偏向于其他线程，要么回复到无锁状态或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。
下图的线程 1 演示了偏向锁初始化的流程，线程 2 演示了偏向锁撤销的流程：
关闭偏向锁
偏向锁在 Java 6 和 Java 7 里是默认启用的，但是它在应用程序启动几秒钟之后才激活，如有必要可以使用 JVM 参数来关闭延迟：-XX:BiasedLockingStartupDelay=0，如果能够确定应用程序里所有的锁通常情况下都处于竞争状态，可以通过 JVM 参数关闭偏向锁：-XX:UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。
（2）轻量级锁
轻量级锁加锁
线程在执行同步块之前，JVM 会现在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头中的 Mark Word 复制到锁记录中，官方称为 Displaced Mark Word。然后线程尝试使用 CAS 将对象头中的 Mark Word 替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。
轻量级锁解锁
轻量级锁解锁时，会使用原子的 CAS 操作将 Displaced Mark Word 替换回到对象头，如果成功，则表示竞争没有发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。
下图是两个线程同时竞争锁，导致锁膨胀的流程图：
因为自旋会消耗 CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。
（3）锁的优缺点对比
| 锁状态 | 25bit | 31bit | 1bit | 4bit | 1bit | 2bit |
|---|---|---|---|---|---|---|
| cms_free | 分代年龄 | 偏向锁 | 锁标志位 | |||
| 无锁 | unused | hashCode | 0 | 01 | ||
| 偏向锁 | ThreadID(54bit) Epoch(2bit) | 1 | 01 | |||
| 锁 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 偏向锁 | 加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级别的差距 | 如果线程间存在锁竞争，会带来额外的锁撤销的消耗 | 适用于只有一个线程访问同步块的情况 |
| 轻量级锁 | 竞争的线程不会阻塞，提高了程序的响应速度 | 始终无法在锁竞争中获得锁的线程，使用自旋会消耗 CPU | 追求响应时间，同步块执行速度非常块 |
| 重量级锁 | 线程竞争不使用自旋，不会消耗 CPU | 线程阻塞，响应时间缓慢 | 追求吞吐量，同步块代码执行速度较慢 |
4、原子操作的实现原理
原子（atomic）的本意是：”不能被进一步分割的最小粒子”，而原子操作（atomic operation）意为 “不可被中断的一个或一系列操作”。在多处理器上实现原子操作就有些复杂。
（1）术语定义
| 术语名称 | 英文 | 说明 |
|---|---|---|
| 缓存行 | Cache line | 缓存的最小操作单位 |
| 比较并交换 | Compare and Swap | CAS 操作需要输入两个数值，一个旧值（期望操作前的值）和一个新值，在操作期间先比较旧值有没有发生变化，如果没有发生变化，才交换成新值，发生了变化则不交换 |
| CPU 流水线 | CPU pipeline | CPU 流水线的工作方式就像工业生产上的装配流水线，在 CPU 中由 5 ~ 6 个不同功能的电路单元组成一条指令处理流水线，然后将一条 X86 指令分成 5 ~ 6 步后再由这些电路单元分别执行，这样就能实现在一个 CPU 时钟周期完成一条指令，因此提高 CPU 的运算速度 |
| 内存顺序冲突 | Memory order violation | 内存顺序冲突一般是由假共享引起的，假共享是指多个 CPU 同时修改同一个缓存行的不同部分而引起其中一个 CPU 的操作无效，当出现这个内存顺序冲突时，CPU 必须清空流水线 |
（2）处理器如何实现原子操作
- 首先所有平台的处理器会自动保证基本的内存操作的原子性：从内存中读取或者写入一个字节是原子的（读写操作都是原子的）；
- 某些平台单处理器对同一个缓存行进行 16/32/64 位的操作是原子的。
处理器提供总线锁定和缓存锁定两个机制来保证复杂的内存操作的原子性。
总线锁保证原子性
第一个机制是通过总线锁保证原子性：如果多个处理器同时对共享变量进行读改写操作（i++就是经典的读改写操作），那么共享变量就会被多个处理器同时进行操作，这样读改写操作就不是原子的，操作完之后共享变量的值会和期望的不一致。
比如说，如果 i = 1，两条线程进行 i++ 操作，我们期望的结果是 i = 3，但是有可能得到 i = 2 的结果，原因可能是多个处理器同时从各自的缓存中读取变量 i，分别进行加 1 操作，然后分别写入系统内存中。那么，想要保证读改写共享变量的操作是原子的，就必须保证一个处理器在读改写共享变量的时候，另一个处理器不能操作缓存了改共享变量内存地址的缓存。
处理器使用 总线锁 来解决这个问题。所谓总线锁就是使用处理器提供的一个 LOCK# 信号，当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞住，此时，该处理器可以独占共享内存。
缓存锁保证原子性
第二个机制是使用缓存锁来保证原子性。在同一时刻，我们只需保证对某个内存地址的操作是原子性即可，但总线锁定把 CPU 和内存之间的通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大，目前处理器在某些场合下使用缓存锁定代替总线锁定来进行优化。
频繁使用的内存会缓存在处理器的 L1、L2 和 L3 高速缓存里，那么原子操作就可以直接在处理器内部缓存中进行，并不需要声明总线锁，所谓 “缓存锁定” 是指内存区域如果被缓存在处理器的缓存行中，并且在 Lock 操作期间被锁定，那么当它执行锁操作回写到内存时，处理器不在总线上声言 LOCK# 信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，因为缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行的数据时，会使缓存行无效。
注意有两种情况下处理器不会使用缓存锁定
（1）当操作的数据不能被缓存到处理器内部，或操作的数据跨多个缓存行（cache line）时，处理器会调用总线锁定；
（2）有些处理器不支持缓存锁定。
针对以上两个机制，Intel 处理器提供了很多 Lock 前缀的指令来实现。例如：
- 位测试和修改指令：BTS、BTR、BTC；
- 交换指令：XADD、CMPXCHG；
- 其他一些操作数和逻辑指令（如 ADD、OR）等等。
被这些指令操作的内存区域就会加锁，导致其他处理器不能同时访问它。
（3）Java 如何实现原子操作
在 Java 中可以通过锁和循环 CAS 的方式来实现原子操作。
使用循环 CAS 实现原子操作
JVM 中的 CAS 操作正是利用了处理器提供的 CMPXCHG 指令实现的。自旋 CAS 实现的基本思路就是循环进行 CAS 操作直到成功为止。
下面的代码实现了一个基于 CAS 线程安全的计数器方法 safeCount 和一个非线程安全的计数器 count：
public class AP {
private AtomicInteger atomicI = new AtomicInteger(0);
private int i = 0;
public static void main(String[] args) {
final AP ap = new AP();
List<Thread> threads = new ArrayList<>(600);
long start = System.currentTimeMillis();
for (int i = 0; i < 100; i++) {
Thread t = new Thread(() -> {
for (int j = 0; j < 10000; j++) {
ap.count();
ap.safeCount();
}
});
threads.add(t);
}
for (Thread thread : threads) {
thread.start();
}
// 等待所有线程执行完毕
for (Thread thread : threads) {
try {
thread.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println(ap.i);
System.out.println(ap.atomicI.get());
System.out.println(System.currentTimeMillis() - start);
}
private void safeCount() {
for (;;) {
int i = atomicI.get();
boolean suc = atomicI.compareAndSet(i, ++i);
if (suc) {
break;
}
}
}
private void count() {
i++;
}
}从 JDK 1.5 开始，JDK 的并发包中提供了一些类来支持基本的原子操作，如 AtomicBoolean（用原子方式更新的 boolean 值）、AtomicInteger（用原子方式更新的 int 值）和 AtomicLong（用原子方式更新的 long 值）。这些原子包装类还提供了一些有用的工具方法，比如以原子的方式将当前值自增 1 和自减 1。
CAS 实现原子操作的三大问题
在 Java 并发包中有一些并发框架也使用了自旋 CAS 的方式来实现原子操作。CAS 虽然很高效的解决的原子操作，但是 CAS 任然存在三大问题：
- ABA 问题；
- 循环时间长开销大；
- 只能保证一个共享变量的原子操作。
ABA 问题
因为 CAS 需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是 A，变成了 B，又变成了 A，那么使用 CAS 进行检查时会发现它的值没有发生变化，但是实际上却变化了。
ABA 问题的解决思路就是使用版本号。在变量前面追加版本号，每次变量更新的时候把版本号加 1，那么 A -> B -> A 就会变成 1A -> 2B -> 3A.
从 Java 1.5 开始，JDK 的 Atomic 包里提供了一个类 AtomicStampedReference 来解决 ABA 问题。这个类的 compareAndSet 方法首先会检查当前引用是否等于预期引用，并且检查当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
// java.util.concurrent.atomic.AtomicStampedReference<V>#compareAndSet()
public boolean compareAndSet(V expectedReference,
V newReference,
int expectedStamp,
int newStamp) {
Pair<V> current = pair;
return
expectedReference == current.reference &&
expectedStamp == current.stamp &&
((newReference == current.reference &&
newStamp == current.stamp) ||
casPair(current, Pair.of(newReference, newStamp)));
}循环时间长开销大
自旋 CAS 如果长时间不成功，会给 CPU 带来非常大的执行开销。如果 JVM 能支持处理器提供的 pause 指令，那么效率会有一定的提供。
pause 指令有两个作用：
（1）可以延迟流水线执行指令（de-pipeline），使 CPU 不会消耗过多的执行资源，延迟的时间取绝于具体实现的版本，在一些处理器上延迟时间是零；
（2）它可以避免在退出循环的时候因内存顺序冲突（Memory Order Violation）而引起 CPU 流水线被清空（CPU Pipeline Flush），从而提高 CPU 的执行效率。
只能保证一个共享变量的原子操作
当对一个共享变量执行操作时，我们可以使用循环 CAS 来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时候就可以用锁。
还有一个取巧的方法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量 i = 2，j = a，合并一下 ij = 2a，然后使用 CAS 来操作 ij。
从 Java 1.5 开始，JDK 提供了 AtomicReference 类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行 CAS 操作。
使用锁机制来实现原子操作
锁机制保证了只有获得锁的线程才能够操作锁定的内存区域。JVM 内部实现了很多中锁机制，有偏向锁、轻量级锁和互斥锁（重量级锁）。
有意思的是除了偏向锁，JVM 实现锁的方式都用了循环 CAS，即当一个线程想进入同步块时使用循环 CAS 的方式来获取锁，当它退出同步块的时候使用循环 CAS 释放锁。
