Java 并发机制底层实现 —— volatile 原理、synchronize 锁优化机制

本书部分摘自《Java 并发编程的艺术》

概述

相信大家都很熟悉如何使用 Java 编写处理并发的代码，也知道 Java 代码在编译后变成 Class 字节码，字节码被类加载器加载到 JVM 里，JVM 执行字节码，最终需要转化为汇编指令在 CPU 上执行。因此，Java 中所使用的并发机制其实是依赖于 JVM 的实现和 CPU 的指令，所以了解 Java 并发机制的底层实现原理也是很有必要的

volatile 的应用

volatile 在多处理器开发中保证了共享变量的可见性。可见性的意思是当一个线程修改一个共享变量时，另外一个线程能立即读取到修改过后的值

1. volatile 的定义

Java 语言规范第三版对 volatile 的定义如下：Java 编程语言允许线程访问共享变量，为了确保共享变量能被准确和一致地更新，线程应该确保通过排它锁单独获得这个变量。排它锁可以使用 synchronized 实现，但 Java 提供了 volatile，在某些情况下比锁更加方便。如果一个字段被声明成 volatile，Java 线程内存模型将确保所有线程看到这个变量的值是一致的

2. volatile 的实现原理

在 Java 中我们可以直接使用 volatile 关键字，但它的底层是怎么实现的呢？被 volatile 变量修饰的共享变量进行写操作的时候会多生成一行汇编代码，这行代码使用了 Lock 指令。Lock 指令在多核处理器下会引发两件事情：

将当前处理器缓存行的数据写回到系统内存
这个写回内存的操作会使在其他 CPU 里缓存了该内存地址的数据无效

为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存后再进行操作，但操作完后不知道何时会写到内存。如果对声明了 volatile 的变量进行写操作，JVM 就会向处理器发送一条 Lock 前缀的指令，将这个变量所在缓存行的数据写回到系统内存。但其他处理器的缓存还是旧值，为了保证各个处理器的缓存是一致的，每个处理器会通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了。当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置为无效状态，当处理器对这个数据进行修改操作时，会重新从系统内存中把数据读到处理器缓存里

synchronized 的应用

在多线程并发编程中 synchronized 一直是元老级角色，很多人称呼它为重量级锁。不过，随着 JavaSE 1.6 对 synchronized 进行了各种优化之后，有些情况下它就并不那么重了

Java 中的每一个对象都可以作为锁，具体表现为以下三种形式：

对于普通同步方法，锁是当前实例对象
对于静态同步方法，锁是当前类的 Class 对象
对于同步方法块，锁是 Synchronized 括号里配置的对象

1. synchronized 原理

JVM 基于进入和退出 Monitor 对象来实现方法同步和代码块同步，但两者的实现细节不一样。代码块同步是使用 monitorenter 和 monitorexit 指令实现，而方法同步是使用另外一种方式实现，细节在 JVM 规范里并没有详细说明，但方法的同步同样可以使用这两个指令来实现

monitorenter 指令是在编译后插入到同步代码块的开始位置，而 monitorexit 是插入到方法结束处和异常处，JVM 要保证每个 monitorenter 必须有对应的 monitorexit 与之配对。任何对象都有一个 monitor 与之相关联，当且一个 monitor 被持有后，它将处于锁定状态。线程执行到 monitorenter 指令时，将会尝试获取对象所对应的 monitor 的所有权，即尝试获得对象的锁

2. 锁的升级

JavaSE 1.6 为了减少获得锁和释放锁带来的性能消耗，引入了偏向锁和轻量级锁，因此在 JavaSE 1.6 中，锁一共有四种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态。这几个状态会随着竞争情况逐渐升级，锁可以升级但不能降级，这是为了提高获得锁和释放锁的效率

3. 偏向锁

研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得。偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中，只有一个线程访问，不存在多线程争用的情况，就会给线程加一个偏向锁，线程不需要触发同步就能获得锁，降低获得锁的代价

偏向锁的获取

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程 ID，以后该线程在进入和退出同步块时不需要进行 CAS 操作来加锁和解锁，只需测试一下对象头的 Mark Word 是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得锁，否则再测试一下 Mark Work 中偏向锁的标识是否设置成 1（表示当前是偏向锁），如果没有设置，使用 CAS 竞争锁，否则尝试使用 CAS 将对象头的偏向锁指向当前线程
偏向锁的撤销

偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行）。它首先会暂停拥有偏向锁的线程，判断持有偏向锁的线程是否活动，如果线程不处于活动状态，则将对象头设置成无锁状态；如果对象仍然活着，撤销偏向锁后恢复到未锁定或轻量级锁的状态
关闭偏向锁

偏向锁在 Java6 和 Java7 里是默认开启的，但是它在应用程序启动几秒之后才激活，如有必要可以使用 JVM 参数来关闭延迟：-XX:BiasedLockingStartupDelay = 0。如果你确定应用程序里所有的锁通常情况下处于竞争状态，可以通过 JVM 参数来关闭偏向锁：-XX:-UseBiasedLocking = false，那么程序默认会进入轻量级锁状态

下图是偏向锁的获得和撤销流程

4. 轻量级锁

传统的重量级锁性能往往不如人意，因为 monitorenter 与 monitorexit 这两个控制多线程同步的 bytecode 原语，是 JVM 依赖操作系统的互斥量来实现的。互斥是一种会导致线程挂起，并在较短的时间内又需要重新调度回原线程的，较为消耗资源的操作，为了优化性能，从 Java6 开始引入了轻量级锁的概念。轻量级锁本意是为了减少多线程进入互斥的几率，并不是要替代互斥，它利用了 CPU 原语 Compare-And-Swap（CAS），尝试在进入互斥前，进行补救

轻量级锁加锁

线程在执行同步块之前，JVM 先在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头中的 Mark Word 复制到锁记录中，官方称为 Displaced Mark Word

然后线程尝试使用 CAS 将对象头中的 Mark Word 替换为指向锁记录的指针，如果成功，当前线程获得锁，否则表示其他线程竞争锁，当前线程尝试使用自旋来获取锁
轻量级锁解锁

轻量级锁解锁时，线程会使用原子的 CAS 操作将 Dispatch Mark Word 替换回到对象头，如果成功，表示没有竞争发生；如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁

下图是轻量级锁及膨胀流程图

因为自旋会消耗 CPU，为了避免无用的自旋，一旦锁升级为重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争

5. 锁的优缺点对比

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级的差距	如果线程间存在锁竞争，会带来额外的锁赊销的消耗	适用于只有一个线程访问同步块场景
轻量级锁	竞争的线程不会阻塞，提高了程序的响应速度	如果始终得不到锁竞争的线程，使用自旋会消耗 CPU	追求响应时间，同步块执行速度非常快
重量级锁	线程竞争不使用自旋，不会消耗 CPU	线程阻塞，响应时间缓慢	追求吞吐量，同步块执行速度较长

巴特西