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	线程阻塞，响应时间缓慢	追求吞吐量，同步块执行速度较长