Java 线程安全与锁
本文主要来自自周志明的《深入理解 Java 虚拟机——JVM高级特性与最佳实践》
文章目录
一、 线程安全定义
当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象是线程安全的。
二、 共享数据的分类
按照线程安全的 “安全程度” 由强至弱来排序，我们可以将 Java 语言中各种操作共享的数据分为以下 5 类：不可变、绝对线程安全、相对线程安全、线程兼容、线程对立。
1. 不可变
在 Java 语言中，不可变一定是线程安全的。不可变就代表了无法被修改，只能被读取，无法修改的对象，无论线程对这个对象进行什么操作，都能得到正确的结果。
- 如果共享数据是一个基本类型，那么可以直接用 final 关键字来保证不可变；
- 如果共享数据是一个对象，就要保证对象的行为不会对其状态产生任何影响，比如可以将对象中带有状态的变量都声明成 final。一个典型的例子就是 String 类，我们调用的任何一个 String 对象的函数，都不会修改它的值，只会直接返回一个新构造的字符串对象
2. 绝对线程安全
这种类型完全满足线程安全的定义，但这需要付出很大的代价，有时候甚至只是不切实际的。在 Java 中标注线程安全的类，也不一定满足绝对的线程安全。
举个例子：
Vector 是一个线程安全的容器，它的很多方法都被 synchronized 修饰，比如 add()、get()、size()，尽管这样效率低，但确实安全了。然而，即使它的方法都被修饰成同步，也不意味着他是绝对线程安全。比如，一个线程调用 remove() 方法，一个进行遍历操作，此时就容易产生越界异常，如果想让他正确执行，还需要对这个 vector 对象进行同步。
3. 相对线程安全
相对的线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单独的操作时线程安全的，我们在调用的时候不需要做额外的保障措施，但对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。
在 Java 中，大部分的线程安全类都属于这种类型，比如 Vector、HashTable、Collections。
4. 线程兼容
线程兼容是指对象本身并不是线程安全，但是可以通过在调用端正确使用同步手段来保证对象在并发环境中可以安全地使用，我们平常说一个类不是线程安全的，绝大多数指的就是这个情况。
在 Java 中，大部分类都是线程兼容的，比如 ArrayList，HashMap 等。
5. 线程对立
线程独立是指无论调用端是否采取了同步措施，都无法在多线程环境中并发使用地代码。
在 Java 中这种类型的代码很少出现，一个例子就是 Thread 的 suspend()和 resume()，如果两个线程同时持有一个对象，一个尝试中断线程一个尝试恢复线程，如果并发进行的话，无论是否进行了同步，目标线程都有存在死锁的风险。
三、 线程安全的实现
1. 互斥同步
互斥同步是常见的一种并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个线程使用。而互斥是实现同步的一种手段，临界区、互斥量和信号量都是主要的互斥实现方式。
Java 中，常用的互斥同步就是 synchronized 和 ReentrantLock。
synchronized
synchronized 是 Java 中的一个关键字，可以用在三个地方：
- 修饰实例方法，作用于当前实例加锁，进入同步代码前要获得当前实例的锁
- 修饰静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁
- 修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁
static public synchronized void test1(){
//......
}
public synchronized void test2(){
//......
}
public void test3{
Integer x = 10;
synchronized (x){
//......
}
}
synchronized 关键字经过编译后，会在同步块的前后分别形成 monitorenter 和 monitorexit 两个字节码指令，这两个字节码都需要一个引用类型的参数来指定要锁定和解锁的对象。如果指定了对象参数，那就是这个对象的引用，如果没有指定，那么他就会去获取实例的引用或类对象的引用作为锁对象。
在虚拟机的规范中，执行 monitorenter 指令首先会获取对象的锁，如果对象没被锁定或已经有了那个对象的锁，那么这个锁的计数器 +1 ，相应的，执行 monitorexit 指令后会将锁计数器 -1 ，当计数器为 0 时，释放这个锁，如果获取锁失败，那么就进入阻塞，等待别的线程释放锁为止。
ReentrantLock
在基本用法上， ReentrantLock 和 synchronized 很相似，不过 synchronized 是将加锁解锁交给虚拟机进行操作，ReentrantLock 则要求在我们在代码上手动的加锁解锁。不过相比起 synchronized，ReentrantLock 拥有一些高级功能，主要是：
- 等待可中断：如果长时间获取不到锁，可以中断等待状态，处理别的事情。
- 公平锁：当多个线程等待某个锁释放时，必须要按申请锁的时间顺序来以此获得锁。
- 锁绑定多个条件：ReentrantLock 对象可以同时绑定多个 Condition 对象作为锁，只用 new Condition() 即可。
private final Lock lock = new ReentrantLock();
public void test4(){
lock.lock();
try{
//......
} finally {
lock.unlock();
}
}
二者对比：
- synchronized 是虚拟机隐式地进行加锁解锁，ReentrantLock 是程序员自己在代码中加锁解锁
- synchronized 已经进行多次优化，性能与 ReentrantLock 相差不大，如果不追求 ReentrantLock 的高级功能，推荐优先考虑 synchronized。
- synchronized 通信通过 wait()，notify()，notifyAll() 这三个方法，ReentrantLock 通信通过 await()，signal()，signalAll() 这三个方法。
2. 非阻塞同步
互斥同步最主要的问题就是线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步。
互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施，那就肯定会出现问题。无论共享数据是否真的会出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。
随着硬件指令集的发展，我们可以使用基于冲突检测的乐观并发策略：先进行操作，如果没有其它线程争用共享数据，那操作就成功了，否则采取补偿措施（不断地重试，直到成功为止）。这种乐观的并发策略的许多实现都不需要将线程阻塞，因此这种同步操作称为非阻塞同步。
CAS
比较并交换（Compare-and-Swap，CAS），CAS 指令需要有 3 个操作数，分别是内存位置（V），旧的预期值（A），新值（B），只有当 V 中的数据等于 A 时，才会将 B 更新到 V 上，否则就不更新。
原子类中的操作使用的就是 CAS 指令，我们可以看看 AtomicInteger 中加法的源码：
public final int getAndAdd(int delta) {
return unsafe.getAndAddInt(this, valueOffset, delta);
}
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
var1 指示对象内存地址，var2 指示该字段相对对象内存地址的偏移，即 var1+var2 才能获取到对象中的存放数据的 value 字段的值，var4 指示操作需要加的数值。通过 getIntVolatile(var1, var2) 得到对象中的数据，通过调用 compareAndSwapInt() 来进行 CAS 比较，如果该字段内存地址中的值等于 var5，那么就更新对象中的数据为 var5+var4。
CAS 存在这样的一个逻辑漏洞：如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检在到它仍然为 A 值，那我们就能说它的值没有被其他线程改变过吗？如果在这段期间它的值曾经被改成了 B，后来又被改问为 A，那 CAS 操作就会误认为它从来没有被改变过。这个漏洞称为 CAS 操作的 “ ABA ” 问题。J.U.C 包中有一个带有标记的原子引用类 “ AtomicStampedReference ”，它可以通过控制变量值的版本来保证 CAS 的正确性。不过目前来说这个类比较 “ 鸡肋 ” ，大部分情况下 ABA 问题不会影响程序并发的正确性，如果需要解决 ABA 问题，改用传统的互斥同步可能会比原子类更高效。
3. 无同步方案
要保证线程安全，并不是一定就要进行同步，两者没有因果关系。同步只是保证共享数据争用时的正确性的手段，如果一个方法本来就不涉及共享数据，那它自然就无须任何同步措施去保证正确性。
可重入代码
这种代码也叫做纯代码，可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误。相对线程安全来说，可重入性是更基本的特性，它可以保证线程安全，即所有的可重入的代码都是线程安全的，但是并非所有的线程安全的代码都是可重入的。
我们可以通过一个简单的原则来判断代码是否具备可重入性：如果一个方法，它的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。
线程本地存储
如果一段代码中所需要的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行。如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。
相当于为每一个线程提供该变量的副本，看似是共享数据进行操作，不过都是在对自己线程中的该数据的副本进行操作，不会影响到别的线程的副本数据。在 Java 中通过 ThreadLocal 类来实现。
四、锁优化
1. 自旋锁与自适应自旋
线程进行挂起和恢复，都会消耗许多的资源，而如果共享数据的锁定只会持续一小段时间，为了这一段时间，将线程挂起再恢复并不值得。我们可以让线程进行循环等待，不放弃处理器的执行时间，只需要等待一会儿就能获取到锁继续操作，这就是自旋锁。
在 JDK1.6 中引入了自适应的自旋锁。自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。
如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次白旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间，比如 100 个循环。另外，如果对于某个锁，自旋很少成功获得过，那在以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。
2. 锁消除
锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除主要是通过逃逸分析来支持，如果堆上的共享数据不可能逃逸出去被其它线程访问到，那么就可以把它们当成私有数据对待，也就可以将它们的锁进行消除。
比如字符串的拼接，JDK1.5 前使用的是 StringBuffer 中的 append() 进行拼接，而 StringBuffer 是一个线程安全类，这就是一个隐式加锁的过程，而现在底层优化了，使用的是 StringBuilder 中的 append() 进行拼接
3. 锁粗化
如果一系列的连续操作都对同一个对象反复加锁和解锁，频繁的加锁操作就会导致性能损耗，因此此时需要将锁的范围扩大，将这些连续加锁解锁的操作，都放在一次加锁解锁中，这就是锁粗化。
之前说的字符串的连续的 append() 方法就属于这类情况。如果虚拟机探测到由这样的一串零碎的操作都对同一个对象加锁，将会把加锁的范围扩展（粗化）到整个操作序列的外部。对于上一节的示例代码就是扩展到第一个 append() 操作之前直至最后一个 append() 操作之后，这样只需要加锁一次就可以了。（JDK1.5 版本前）
4. 轻量级锁
JDK 1.6 引入了偏向锁和轻量级锁，从而让锁拥有了四个状态：无锁状态（unlocked）、偏向锁状态（biasble）、轻量级锁状态（lightweight locked）和重量级锁状态（inflated）。
在虚拟机中，每个对象都有一个对象头，其中对象头分为两个部分，第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、 GC 分代年龄（Generational GC Age）等这部分数据的长度在 32 位和 64 位的虚拟机中分别为 32bit 和 64bit，官方称它为 “ Mark Word ” ，它是实现轻量级锁和偏向锁的关键。另外一部分用于存储指向方法区对象类型数据的指针，如果是数组对象的话，还会有一个额外的部分用于存储数组长度。
轻量级锁主要针对的是第一部分，即：Mark Word 部分。
对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率， MarkWord 被设计成-个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。例如，在 32 位的 HotSpot 虚拟机中对象未被锁定的状态下，MarkWord 的 32bit 空间中的 25bit 用于存储对象哈希码(HashCode)，4bit 用于存储对象分代年龄, 2bit 用于存储锁标志位, 1bit 固定为 0，在其他状态（轻量级锁定、重量级锁定、GC 标记、可偏向）下对象的存储内容见下表，存储内容和标志位是一一对应的：
| 存储内容 | 标志位 | 状态 |
|---|---|---|
| 对象哈希码、对象分代年龄 | 01 | 未锁定 |
| 指向锁记录的指针 | 00 | 轻量级锁定 |
| 指向重量级锁的指针 | 10 | 重量级锁定 |
| 空，不需要记录信息 | 11 | GC 标记 |
| 偏向线程 ID、偏向时间戳、对象分代年龄 | 01 | 可偏向 |
下面来看一下轻量级锁的加锁过程图：
当代码进入同步块时，如果该同步对象没有被锁定，该对象的对象头会如上图所示，标志位为 01 状态，存的是哈希码、分代年龄等信息，此时虚拟机会在当前线程的栈帧中，建立一个名为锁记录的空间，即 Lock Record ，用于存储同步对象的对象头，如下图中的栈帧所示。
然后，虚拟机使用 CAS 操作尝试将对象的 Mark Word 更新为指向 Lock Record 的指针。如果成功，就代表这个线程拥有了该对象的锁，并将同步对象的锁标志位转为 00 状态。
如果 CAS 操作失败了，虚拟机首先会检查对象的 Mark Word 是否指向当前线程的虚拟机栈，如果是的话说明当前线程已经拥有了这个锁对象，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其他线程线程抢占了。如果有两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁。
上面描述的是轻量级锁的加锁过程，它的解锁过程也是通过 CAS 操作来进行的，如果对象的 Mark Word 仍然指向着线程的锁记录，那就用 CAS 操作把对象当前的 Mark Word 和线程中复制的 Displaced Mark Word 替换回来，如果替换成功，整个同步过程就完成了。如果替换失败，说明有其他线程尝试过获取该锁，那就要在释放锁的同时，唤醒被挂起的线程。
5. 偏向锁
偏向锁的 “ 偏 ” ，就是偏心的 “ 偏 ” 、偏袒的 “ 偏 ” ，它的意思是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。
假设当前虚拟机启用了偏向锁（启用参数-XX:+UseBiasedLocking，这是 JDK 1.6 的默认值），那么，当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为 “ 01 ” ，即偏向模式。同时使用 CAS 操作把获取到这个锁的线程的 ID 记录在对象的 MarkWord 之中，如果 CAS 操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如 Locking、Unlocking 及对 Mark Word 的 Update 等）。
当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向（Revoke Bias）后恢复到未锁定（标志位为“01”）或轻量级锁定（标志位为 “00” ）的状态，后续的同步操作就如之前介绍的轻量级锁那样执行。偏问锁、轻量级锁的状态转化及对象 MarkWord 的关系如图所示。
