第十三章 线程安全与锁优化

13.2 线程安全

13.2.1 Java语言中的线程安全

我们可以将Java 语言中各种操作共享的数据分为以下五类：

1. 不可变
2. 绝对线程安全
3. 相对线程安全
4. 线程兼容
5. 线程对立

13.2.2 线程安全的实现方法

1.互斥同步

“互斥同步”这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。

两种手段：synchronized关键字和Lock类

synchronized关键字：

• 被 synchronized 修饰的同步块对同一条线程来说是可重入的。这意味着同一线程反复进入同步块也不会出现自己把自己锁死的情况。
• 被 synchronized 修饰的同步块在持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他线程的进入。这意味着无法像处理某些数据库中的锁那样，强制已获取锁的线程释放锁；也无法强制正在等待锁的线程中断等待或超时退出

Lock接口最常见的实现可重入锁（ReentrantLock）：

ReentrantLock 与 synchronized 相比增加了一些高级功能，主要有以下三项：等待可中断、可实现公平锁及锁可以绑定多个条件。

• 等待可中断
• 公平锁
• 锁绑定多个条件

2.非阻塞同步

​ 互斥同步面临的主要问题是进行线程阻塞和唤醒所带来的性能开销，因此这种同步也被称为阻塞同步（Blocking Synchronization）。从解决问题的方式上看，互斥同步属于一种悲观的并发策略，每次都要加锁。这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开销，也会产生线程在磁盘内存间换入换出。

​ 基于冲突检测的乐观并发策略，通俗地说就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现没有竞争的共享数据为止。这种乐观并发策略的实现不再需要把线程阻塞挂起，因此这种同步操作被称为非阻塞同步（Non-Blocking Synchronization），使用这种措施的代码也常被称为**无锁（Lock-Free）**编程。
使用乐观并发策略需要“硬件指令集的发展”，我们必须要求操作和冲突检测这两个步骤具备原子性。指令常用的有：

• 测试并设置（Test-and-Set）；
• 获取并增加（Fetch-and-Increment）；
• 交换（Swap）；
• 比较并交换（Compare-and-Swap，下文称 CAS）；
• 加载链接/条件储存（Load-Linked/Store-Conditional，下文称 LL/SC）。

Java中实现是CAS。

3.无同步方案

要保证线程安全，也并非一定要进行阻塞或非阻塞同步，同步与线程安全两者没有必然的联系。同步只是保障存在共享数据争用时正确性的手段，如果能让一个方法本来就不涉及共享数据，那它自然就不需要任何同步措施去保证其正确性，因此会有一些代码天生就是线程安全的。

简单介绍其中的两类：

• 可重入代码
• 线程本地存储

13.3 锁优化

13.3.1 自旋锁与自适应自旋

自旋锁产生

起因：

讨论互斥同步的时候，提到了互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给 Java 虚拟机的并发性能带来了很大的压力。

方案：

让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），自旋次数默认值是十次，这项技术就是所谓的自旋锁，也就是jvm给你自旋一会儿，而不是写代码自旋。

JDK6中对自旋锁的优化，引入了自适应的自旋。

13.3.2 锁消除

锁消除是指虚拟机即时编译器在运行时， 对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除（例如System.out.print，其实他内部是有同步代码块的）。锁消除的主要判定依据来源于逃逸分析的数据支持（第 11 章已经讲解过逃逸分析技术）。

13.3.3 锁粗化

原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变少，即使存在锁竞争，等待锁的线程也能尽可能快地拿到锁。

​ 但是如果加锁操作是出现在循环体之中，那么就会造成不必要的性能损耗，所以就会粗化到循环外面。

13.3.4 轻量级锁

0.目的

轻量级锁并不是用来代替重量级锁的，它设计的初衷是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

1.对象内存布局

对象头分为两部分：

• 第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、 GC 分代年龄（Generational GC Age）等。这部分数据的长度在 32 位和64 位的 Java 虚拟机中分别会占用 32 个或 64 个比特，官方称它为“Mark Word”。这部分是实现轻量级锁和偏向锁的关键。

• 另外一部分用于存储指向方法区对象类型数据的指针，如果是数组对象，还会有一个额外的部分用于存储数组长度。
  
  2.轻量级锁过程

​ 在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（ Lock Record）的空间，用于存储锁对象目前的 Mark Word 的拷贝（官方为这份拷贝加了一个 Displaced 前缀，即Displaced Mark Word），这时候线程堆栈与对象头的状态如图 13-3 所示。

然后，虚拟机将使用 CAS 操作尝试把对象的 Mark Word 更新为指向 Lock Record 的指针。如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象 MarkWord 的锁标志位（Mark Word 的最后两个比特）将转变为“00”，表示此对象处于轻量级锁定状态。这时候线程堆栈与对象头的状态如图 13-4 所示。

如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁，锁标志的状态值变为“10”，此时 MarkWord 中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也必须进入阻塞状态。

如何解锁：

通过 CAS 操作来进行的，如果对象的 Mark Word 仍然指向线程的锁记录，那就用 CAS 操作把对象当前的Mark Word 和线程中复制的 Displaced Mark Word 替换回来。假如能够成功替换，那整个同步过程就顺利完成了；如果替换失败，则说明有其他线程尝试过获取该锁，就要在释放锁的同时，唤醒被挂起的线程。

13.3.5 偏向锁

偏向锁也是 JDK 6 中引入的一项锁优化措施，如果说轻量级锁是在无竞争的情况下使用CAS 操作去消除同步使用的互斥量，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能（就是在无竞争的情况下直接取消锁，也就是锁消除）。

​ 假设当前虚拟机启用了偏向锁（ 启用参数-XX：+UseBiased Locking，这是自 JDK 6 起 HotSpot 虚拟机的默认值），那么当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为“01”、把偏向模式设置为“1”，表示进入偏向模式。同时使用 CAS 操作把获取到这个锁的线程的 ID 记录在对象的Mark Word 之中。如果 CAS 操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁、解锁及对 Mark Word 的更新操作等）。

​ **一旦出现另外一个线程去尝试获取这个锁的情况，偏向模式就马上宣告结束。**根据锁对象目前是否处于被锁定的状态决定是否撤销偏向（ 偏向模式设置为“0”），撤销后标志位恢复到未锁定（标志位为“01”）或轻量级锁定（标志位为“00”）的状态，后续的同步操作就按照上面介绍的轻量级锁那样去执行。偏向锁、轻量级锁的状态转化及对象Mark Word 的关系如图 13-5 所示。

问题：

当对象进入偏向状态的时候， MarkWord 大部分的空间（23 个比特）都用于存储持有锁的线程 ID 了，这部分空间占用了原有存储对象哈希码的位置，那原来对象的哈希码怎么办呢？

在 Java 语言里面一个对象如果计算过哈希码，就应该一直保持该值不变（强烈推荐但不强制，因为用户可以重载 hashCode()方法按自己的意愿返回哈希码），否则很多依赖对象哈希码的 API 都可能存在出错风险。而作为绝大多数对象哈希码来源的Object::hashCode()方法，返回的是对象的一致性哈希码（Identity Hash Code），这个值是能强制保证不变的，它通过在对象头中存储计算结果来保证第一次计算之后，再次调用该方法取到的哈希码值永远不会再发生改变。**因此，当一个对象已经计算过一致性哈希码后，它就再也无法进入偏向锁状态了；而当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁。**在重量级锁的实现中，对象头指向了重量级锁的位置，代表重量级锁的ObjectMonitor 类里有字段可以记录非加锁状态（标志位为“01”）下的 Mark Word，其中自然可以存储原来的哈希码。