第2章 Java 并发机制的底层实现原理
Java 代码在编译后会变成 Java 字节码，字节码被类加载器加载到 JVM 里，JVM 执行字节码，JVM 再将字节码翻译转化为汇编指令，使其在 CPU 上执行。
Java 中所使用的并发机制依赖于 JVM 的实现和 CPU 的指令。本章将深入底层一起探索下 Java 并发机制的底层实现原理。
一、volatile 的应用
在多线程并发编程中 synchronized 和 volatile 都扮演着重要的角色，volatile 是轻量级的 synchronized，它在多处理器开发中保证了共享变量的”可见性”。
可见性就是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。
如果 volatile 变量修饰符使用恰当的话，它比 synchronized 的使用和执行成本更低，因为它不会引起线程上下文的切换和调度。本文将深入分析在硬件层面上 Intel 处理器是如何实现 volatile 的，通过深入分析帮助我们正确地使用 volatile 变量。
移步阅读笔者之前写过的学习笔记：
细说Java多线程之内存可见性：学习笔记（一）
细说Java多线程之内存可见性：学习笔记（二）
1.1 volatile 的定义与实现原理
1.1.1 volatile 定义
Java 语言规范第 3 版中对 volatile 的定义如下：Java 编程语言允许线程访问共享变量，为了确保共享变量能被准确和一致地更新，线程应该确保通过排他锁单独获得这个变量。因此 Java 语言提供了 volatile，在某些情况下比 synchronized 锁要更加方便。如果一个字段被声明成 volatile，Java 线程内存模型确保所有线程看到这个变量的值是一致的。
从上述描述中可知：volatile 可以保证共享变量的可见性，并没有保证原子性。
CPU 术语说明：
volatile 保证线程的可见性，在 JVM 的底层中一定使用到了 CPU 操作指令，因此有必要先了解一下 CPU 中的一些基础术语：
- 内存屏障（memory barriers）
是一组处理器指令，用于实现对内存操作的顺序限制。 - 缓冲行（cache line）
缓存中可以分配的最小存储单位。处理器填写缓存线时会加载整个缓存线，需要使用多个主内存的读周期。 - 原子操作（atomic operations）
不可中断的一个或一系列操作。 - 缓冲行填充（cache line fill）
当处理器识别到从内存中读取操作数是可缓存的，处理器读取整个缓存行到适当的缓存（L1，L2，L3 的或所有）。 - 缓冲命中（cache hit）
如果进行高速缓存行填充操作的内存位置仍然是下次处理器访问的地址时，处理器从缓存中读取操作数，而不是从内存读取。 - 写命中（write hit）
当处理器将操作数写回到一个内存缓存的区域时，它首先会检查这个缓存的内存地址是否在缓存行中，如果存在一个有效的缓存行，则处理器将这个操作数写回到缓存，而不是写回到内存，这个操作被成为写命中。 - 写缺失（write misses the cache）
一个有效的缓存行被写入到不存在的内存区域。
1.1.2 volatile 的实现原理
如果对声明了 volatile 的共享变量进行写操作时，JVM 就会向处理器发送一条 Lock 前缀的指令（JVM 翻译转化成的汇编指令），目的就是将这个变量所在缓存行的数据写回到系统内存。
当某个线程写完自己工作内存的操作数，并通过 JVM 携带的 Lock 前缀指令告知当前写完的操作数要及时更新到系统内存。
仅仅这一步还不够，因为其他线程的工作内存中的操作数还是原来的状态，而不是当前系统内存中最新的操作数。同时处理器本身的机制决定了线程之前不能直接通信：为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存（L1，L2或其他）后再进行操作，但操作完不知道何时会写到内存。
那如何保证其他线程操作数之前能拿到最新的操作数呢？
在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址在系统内存中被修改了，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。
1.1.3 volatile 的两条实现原则
Lock 前缀指令会引起处理器缓存回写到内存
对于不同的处理器版本，Lock 前缀指令导致在执行指令期间，对声言处理器的
LOCK#信号有不同的处理机制：对于 Intel 486 和 Pentium 处理器，LOCK# 信号确保在声言该信号期间，处理器可以独占任何共享内存，因为它会锁住总线，导致其他 CPU 不能访问总线，不能访问总线就意味着不能访问系统内存。
在 P 6 和目前的处理器中，如果访问的内存区域已经缓存在处理器内部，则不会声言 LOCK# 信号。它会锁定这块内存区域的缓存并回写到内存，并使用缓存一致性机制来确保修改的原子性，此操作被称为**”缓存锁定”**，缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据。
一个处理器的缓存回写到内存会导致其他处理器的缓存无效
IA-32 处理器和 Intel 64 处理器使用
MESI（修改、独占、共享、无效）控制协议去维护内部缓存和其他处理器缓存的一致性。处理器的嗅探技术：
在多核处理器系统中进行操作的时候，处理器能嗅探其他处理器访问系统内存和它们的内部缓存，以保证它的内部缓存、系统内存和其他处理器的缓存的数据在总线上保持一致。
例如，在 Pentium 和 P 6 family 处理器中，如果通过嗅探一个处理器来检测其他处理器打算写内存地址（并且这个地址当前处于共享状态），那么正在嗅探的处理器将使它的缓存行无效，在下次访问相同内存地址时，强制执行缓存行填充。
1.1.4 volatile的使用优化
在 JDK 7 的并发包里新增一个队列集合类Linked-TransferQueue，它在使用 volatile 变量时，用一种追加字节的方式来优化队列出队和入队的性能。
这个内部类PaddedAtomicReference相对于父类AtomicReference只做了一件事情，就是将共享变量追加到 64 字节。因为目前主流处理器高速缓存行是 64 个字节宽，不支持部分填充缓存行，通过追加到 64 字节的方式填满高速缓冲区的缓存行，避免各元素加载到同一缓存行而互相锁定。
并不是所有的使用 volatile 变量时都应该追加到 64 字节：
1）对于缓存行非 64 字节宽的处理器。如 P 6 系列和奔腾处理器，它们的 L1 和L2 高速缓存行是32个字节宽。
2）如果共享变量不被频繁写的话，锁的机率很小，就没必要通过追加字节的方式来避免相互锁定。因为追加字节的方式需要处理器读取更多的字节到高速缓冲区，需要更高的性能消耗。
不过这种追加字节的方式在Java 7下可能不生效，因为Java 7变得更加智慧，它会淘汰或重新排列无用字段，需要使用其他追加字节的方式。
二、synchronized 的应用
synchronized 常被称为重量级锁，但是随着 Java SE 1.6 对 synchronized 进行了各种优化之后，有些情况下它就并不那么重了，因为有了偏向锁和轻量级锁，以及锁的存储结构和升级过程。
Java 中的每一个对象都可以作为锁。具体表现为以下 3 种形式：
- 对于普通同步方法，锁是当前实例对象（this）。
- 对于静态同步方法，锁是当前类的 Class 对象。
- 对于同步方法块，锁是 synchonized 括号里配置的对象。
synchonized 在 JVM 里的实现原理
从 JVM 规范中可以看到 Synchonized 在 JVM 里的实现原理：JVM 基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。
代码块同步是使用monitorenter和monitorexit指令实现的，而方法同步是使用另外一种方式实现（JVM 规范里并没有详细说明），但可以使用这两个指令来实现。
JVM 里的 Monitor
monitorenter指令是在编译后插入到同步代码块的开始位置，monitorexit指令是插入到方法结束处和异常处。
JVM 要保证每个 monitorenter 必须有对应的 monitorexit 与之配对。任何对象都有一个 monitor 与之关联，当且一个 monitor 被持有后，它将处于锁定状态。线程执行到 monitorenter 指令时，将会尝试获取对象所对应的 monitor 的所有权，即尝试获得对象的锁。
2.2.1 Java 对象头
synchronized 用的锁是存在 Java 对象头里的。Java 对象头针对数组类型对象和非数组类型对象存储的信息不同，前者存 3 个字宽（Word）的信息，后者存 2 个字宽的信息。
在不同的位数操作系统中，字宽对应的字节大小不同：
- 在 32 位虚拟机中，1 字宽等于 4 字节，即 32 bit
- 在 64 位虚拟机中，1 字宽等于 8 字节，即 64 bit
每个字宽中存储着不同的信息标识：
在 Java 对象头里的Mark Word里默认存储对象的 HashCode、分代年龄和锁标记位。32 位 JVM 的Mark Word的默认存储结构如下图所示：
在运行期间，Mark Word 里存储的数据会随着锁标志位的变化而变化，以下 4 种数据变化：
用一张图来描述上述的各种表结构之间的关系：
在 64 位虚拟机下，Mark Word 是 64 bit 大小的，其存储结构如下表：
注意：上表中偏向锁的状态的头信息中出现了线程 ID，并且偏向锁的值为 1。
三、锁的升级与对比
Java SE 1.6 为了减少获得锁和释放锁带来的性能消耗，引入了”偏向锁”和”轻量级锁”，锁一共有 4 种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态。
这几个状态会随着竞争情况逐渐升级，并且这种升级之后不可降级，因此偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。
3.1 偏向锁
大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。偏向锁在 Java 6 和 Java 7 里是默认启用的，但是它在应用程序启动几秒钟之后才激活。
3.1.1 偏向锁的初始化
当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程 ID，存储之前会测试一下对象头的 Mark Word 里是否存储着指向当前线程的偏向锁。
如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下 Mark Word 中偏向锁的标识是否设置成 1（表示当前是偏向锁）：如果没有设置，则使用CAS竞争锁；如果设置了，则尝试使用 CAS 将对象头的偏向锁指向当前线程。
3.1.2 偏向锁的撤销
偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。
偏向锁撤销的前提是需要等待全局安全点，即在这个时间点上没有正在执行的字节码。撤销之后的偏向锁会变成无锁状态，即具体 Mark Word 信息体中不含本线程 ID。
以下为撤销流程文字描述：
偏向锁撤销时首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将对象头设置成无锁状态；如果线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的 Mark Word 要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。
下图中的线程 1 演示了偏向锁初始化的流程，线程 2 演示了偏向锁撤销的流程。
3.1.3 偏向锁的关闭
偏向锁在 Java 6 和 Java 7 里会默认在应用程序启动几秒钟之后激活，可以使用 JVM 参数来关闭延迟：-XX:BiasedLockingStartupDelay=0。
如果确定应用程序里所有的锁通常情况下处于竞争状态，可以通过 JVM 参数关闭偏向锁：-XX:-UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。
3.2 自旋锁
首先，内核态与用户态的切换上不容易优化。但通过自旋锁，可以减少线程阻塞造成的线程切换（包括挂起线程和恢复线程）。
线程的阻塞和唤醒需要 CPU 从用户态转为核心态，频繁的阻塞和唤醒对 CPU 来说是一件负担很重的工作。同时可以发现，很多对象锁的锁定状态只会持续很短的一段时间，例如整数的自加操作，在很短的时间内阻塞并唤醒线程显然不值得，为此引入了自旋锁。
所谓”自旋”，就是让线程去执行一个无意义的循环，循环结束后再去重新竞争锁，如果竞争不到继续循环，循环过程中线程会一直处于 running 状态，但是基于 JVM 的线程调度，会出让时间片，所以其他线程依旧有申请锁和释放锁的机会。
自旋锁省去了阻塞锁的时间空间（队列的维护等）开销，但是长时间自旋就变成了”忙式等待”，忙式等待显然还不如阻塞锁。如果持有锁的线程执行的时间超过自旋等待的最大时间扔没有释放锁，就会导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会停止自旋进入阻塞状态。
自旋锁的目的是为了占着 CPU 的资源不释放，等到获取到锁立即进行处理。但是如果自旋执行时间太长，会有大量的线程处于自旋状态占用 CPU 资源，进而会影响整体系统的性能。因此自旋的周期选的额外重要。
JVM 对于自旋周期的选择，JDK 1.5 中这限度是一定要写死，在 JDK 1.6 引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不在是固定的了，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定，基本认为一个线程上下文切换的时间是最佳的一个时间，同时 JVM 还针对当前 CPU 的负荷情况做了较多的优化。
3.3 轻量级锁
自旋锁的目标是降低线程切换的成本。如果锁竞争激烈，我们不得不依赖于重量级锁，让竞争失败的线程阻塞；如果完全没有实际的锁竞争，那么申请重量级锁都是浪费的。轻量级锁的目标是，减少无实际竞争情况下，使用重量级锁产生的性能消耗，包括系统调用引起的内核态与用户态切换、线程阻塞造成的线程切换等。因此轻量级锁是相对于重量级锁而言的。
轻量级锁是由偏向锁升级来的，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁。
轻量级锁的加锁
线程在执行同步块之前，JVM 会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的 Mark Word 复制到锁记录中，官方称为 Displaced Mark Word。然后线程尝试使用 CAS 将对象头中的 Mark Word 替换为指向锁记录的指针。
- 如果成功，当前线程获得锁。
- 如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。
当轻量级锁使用自旋的方式获取锁仍然失败时，表示存在其他线程竞争锁（两条或两条以上的线程竞争同一个锁），则轻量级锁会膨胀成重量级锁。
轻量级锁的解锁
轻量级解锁时，会使用原子的 CAS 操作来将 Displaced Mark Word 替换回到对象头：
- 如果成功，则表示同步过程已完成。
- 如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。在释放锁的同时，唤醒被挂起的线程。
轻量锁与偏向锁不同的是：
- 轻量级锁每次退出同步块都需要释放锁，而偏向锁是在竞争发生时才释放锁
- 每次进入退出同步块都需要 CAS 更新对象头
- 争夺轻量级锁失败时，自旋尝试抢占锁
因为自旋会消耗 CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。
3.4 重量级锁
重量锁在 JVM 中又叫对象监视器（Monitor），它很像 C 中的Mutex，除了具备 Mutex(0|1) 互斥的功能，它还负责实现了 Semaphore （信号量）的功能，也就是说它至少包含一个竞争锁的队列，和一个信号阻塞队列（wait 队列），前者负责做互斥，后一个用于做线程同步。
3.5 锁的优缺点的对比
偏向锁
- 优点
加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距。 - 缺点
如果线程间存在锁竞争，会带来额外的锁撤销的消耗。 - 适用场景
适用于只有一个线程访问同步块场景。
轻量级锁
- 优点
竞争的线程不会阻塞，提高了程序的响应速度。 - 缺点
如果始终得不到锁竞争的线程使用自旋会消耗 CPU。 - 适用场景
追求响应时间，锁占用时间很短（同步块执行速度非常快）。
重量级锁
- 优点
线程竞争不使用自旋，不会消耗 CPU 。 - 缺点
线程阻塞，响应时间缓慢。 - 适用场景
追求吞吐量，同步块执行速度较长。