【JVM.12】线程安全与锁优化

一.概述

　　面向过程的编程思想极大地提升了现代软件开发的生产效率和软件可以达到的规模，但是现实世界与计算机世界之间不可避免地存在一些差异，本节就如何保证并发的正确性和如何实现线程安全讲起。

 

二.线程安全

　　“线程安全”这个名称，在Google 中搜索它的概念，找到的类似于：“如果一个对象可以安全地被多个线程同时使用，那它就是线程安全的” 这样的定义----并不能说它不正确，但是人们无法从中获取任何信息。

　　笔者认为《Java Concurrency In Practice》的作者 Brian Goetz 对“线程安全”有一个比较恰当的定义：“当多个线程访问一个对象时，如何不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方法进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象就是线程安全的”。

1.　　Java语言中的线程安全

　　在这里我们可以不把线程安全当做一个非真既假的二元排他选项来看待，按照线程安全的“安全程度” 由强至弱来排序，我们可以将Java 语言中各种操作共享的数据分为以下5类：不可变、绝对线程安全、相对线程安全、线程兼容、线程对立。

　　（1）.不可变

　　在Java 语言中（特质 JDK1.5之后），不可变得对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再采取任何的线程安全保障措施，在上一节我们谈到 final 关键字带来的可见性时曾经提到过这一点，这要一个不可变的对象被正确的构建出来，那其外部的可见状态永远不会改变。“不可变”带来的安全性时最简单最纯粹的。

　　如果共享数据时一个基本数据类型，那么只要在定义时使用 final 关键字修饰它就可以保证它是不可变的。如果共享数据是一个对象，那就需要保证对象的行为不会对其状态产生任何影响才行，例如 java.lang.String 类的对象，它是一个典型的不可变对象，我们调用它的 substring()、replace()、concat() 这些方法都不会影响它原来的值，只会返回一个新构造的字符串对象。

　　保证对象行为不影响自己状态的途径有很多种，其中最简单的就是把对象中带有状态的变量都声明为 final ，这样在构造函数结束之后，他就是不可变的，例如 java.lang.Integer 构造函数所示。

public final class Integer extends Number implements Comparable<Integer> {
private final int value;
public Integer(int var1) {
this.value = var1;
}
...

　　在Java API 中符合不可变要求的类型，除了上面提到的 String 之外，常用的还有枚举类型，以及 java.lang.Number 的部分子类，如 Long 和 Double 。 原子类 AtomicInteger 和 AtomicLong 则并非不可变的，不妨可以看看其源码。

　　（2）.绝对线程安全

　　在Java API 中标注自己是线程安全的类，大多数都不是绝对的线程安全。我们可以通过 Java API 中一个不是“绝对线程安全”的线程安全类来看看这个的“绝对” 是什么意思。

　　private static Vector<Integer> vector = new Vector<>();

public static void main(String[] args) {
while (true) {
//初始一个 Vector<Integer>
for (int i = 0; i < 10; i++) {
vector.add(i);
}
Thread removeThread = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < vector.size(); i++) {
vector.remove(i);
}
}
});
Thread printThread = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < vector.size(); i++) {
　　　　　　　　　　　　　　System.out.print(vector.get(i));
//System.out.println(vector.get(i)); //最好不要换行输出 可能太快了 看不到异常信息
}
}
});

removeThread.start();
printThread.start();

//不要同时产生过多线程
while (Thread.activeCount() > 20);
}
}

运行结果　

1664159371591357916641593715913579012345678916641591357951357915954804844666339991
Exception in thread "Thread-380" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
at java.util.Vector.remove(Vector.java:831)
at jvm.concurrence.Test$1.run(Test.java:19)
at java.lang.Thread.run(Thread.java:748)

　　很显然，尽管这里使用到的 Vector 的 get() 、remove()、 size() 方法都是同步的，但是在多线程的环境中，如果不在方法调用端做额外的同步措施的话，使用这段代码仍然是不安全的，因为如果另一个线程恰好在错误的时间里删除了一个元素，导致序号 i 已经不再可用的话，再用 i 访问数组就会抛出 ArrayIndexOutOfBoundsException 。因此我们不得不改为：

Thread removeThread = new Thread(new Runnable() {
@Override
public void run() {
synchronized (vector) {
for (int i = 0; i < vector.size(); i++) {
vector.remove(i);
}
}
}
});
Thread printThread = new Thread(new Runnable() {
@Override
public void run() {
synchronized (vector) {
for (int i = 0; i < vector.size(); i++) {
System.out.print(vector.get(i));
}
}
}
});

　　（3）.相对线程安全

　　相对线程安全及时我们通常意义上所讲的线程安全，它需要保证对这个对象单独的操作时线程安全的，我们再调用的时候不需要做额外的保证措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。

　　上面的两个代码案例，就是相对线程安全的明显表现。

　　在Java 语言中，大部分的线程安全都是属于这种类型，例如 Vector、HashTable、Collections的 synchronizeCollection() 方法包装的集合等。

　　（4）.线程兼容

　　线程兼容是指对象本身并不是线程安全的，但是可以通过再调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用，我们常说一个类不是线程安全的，绝大多数时候指的是这一种情况。

　　Java API 中大部分的类都是属于线程兼容的，如与前面的 Vector 和 HashTable 相对应的集合类 ArrayList 和 HashMap 等。

　　（5）.线程对立

　　线程对立是指无论调用端是否采取了同步措施，都无法再多线程环境中并发使用的代码。由于Java 语言天生就具备多线程特性，线程对立这种排斥多线程的代码是很少出现的，而且通常都是有害的，应当尽量避免。

　　一个线程对立的例子是 Thread 类的 suspend() 和 resume() 方法 ，但是都已经被 JDK声明废弃了。常见的线程对立的操作还有 System.setIn() 、 System.SetOut() 、 System.runFinalizersOnExit() 等。

 

2.　　线程安全的实现方法

　　了解什么是线程安全之后，紧接着就是我们应该如何实现线程安全？本节中，代码编写如何实现线程安全和 虚拟机如何实现同步与锁这两者都会有所涉及。

　　（1）互斥同步

　　互斥同步是常见的一种并发正确性保障手段（悲观锁）。 最基本的互斥同步手段就是 synchronized 关键字， synchronized 关键字经过编译之后，会在同步块的前后分别形成 monitorenter 和 monitorexit 这两个字节码指令，这两个字节码都需要一个 refence 类型的参数来指明要锁定和解锁的对象。如果Java 程序中的 synchronized 明确指定了对象参数，那就是这个对象的 reference； 如果没有明确指定，那就根据 synchronized 修饰的是实例方法还是类方法，去取对应的对象实例或Class 对象来作为锁对象。

　　根据虚拟机规范的要求，在执行 monitorenter 指令时，首先要尝试获取对象的锁。（这是个很关键的点：如果同一个类里多个 synchronized 方法，它们是共用一个锁的。那么一个类里面有两个synchronized方法不可以同步执行）

　　除了 synchronized 之外，我们还可以使用 java.util.concurrent（下文称 JUC）包中的重入锁（ReentrantLock）来实现同步，在基本用法上，ReentrantLock 与 synchronized 很相似，它们都具备一样的线程重入特性，只是代码写法上有点区别。不过，相比synchronized ，ReentrantLock 增加了一些高级功能，主要有一下三项：等待可中断、可实现公平锁、锁可以绑定多个条件。

• 等待可中断是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情，可中断特性对处理执行时间非常长的同步块很有帮助。
• 公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。 synchronized 中的锁时非公平锁， ReentrantLock 默认情况下也是非公平锁，但是可以通过带布尔值的构造函数要求使用公平锁。
• 锁绑定多个条件是指一个ReentrantLock 对象可以绑定多个 Condition 对象，而在 synchronized 中，锁对象的 wait()、 notify()、 notifyAll() 方法可以实现一个隐含的条件，如果要和多于一个的条件关联时，就不得不额外地添加一个锁，而ReentrantLock 则无需这样做，只需要多次调用 newCondition() 方法即可。

　　 关于 synchronized 和 ReentrantLock 的性能问题，在 JDK1.6 之后 优先考虑使用 synchronized 来进行同步。

　　（2）非阻塞同步

　　互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步。随着硬件指令集的发展，我们有了另外一个选择：基于冲突检测的乐观并发策略，通俗地说，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采取其他的补偿措施，这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步。

　　为什么笔者说使用乐观并发策略需要“硬件指令集的发展”才能进行呢？因为我们需要操作和冲突检测这两个步骤具备原子性，靠什么来保证呢？如果这里再使用互斥同步来保证就失去了意义了，所以我们只能靠硬件来完成这件事情，硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成，这类指令常有：

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

　　其中，前面3条是20世纪就已经存在于大多数指令集中的处理器指令，后面两条是新增的。

　　CAS 指令需要有3个操作数，分别是 内存位置 V、旧的预期值 A、新值 B。CAS 指令执行时，当且仅当V 符合就预期值A 时，处理器用新值B 更新V 的值，否则他就不执行更新，但无论是否更新了V 值，都会返回V 的旧值。

　　在JDK1.5 之后，Java程序中才可以使用 CAS操作，该操作由 sun.misc.Unsafe 类里面的 compareAndSwapInt() 和 compareAndSwapLong() 等几个方法包提供。

　　由于Unsafe 类不是提供给用户程序调用的类（只有启动类加载器 Bootstrap ClassLoader 加载的Class才能访问它），因此如果不采用反射手段，我们只能通过其他的Java API 来间接使用它，如 JUC包里面的 原子类。

　　不妨拿一段在上一章没解决的问题看看使用 CAS 操作来避免阻塞同步。

public class AtomicTest {

public static AtomicInteger race = new AtomicInteger(0);

public static void increase() {
race.incrementAndGet();
}

private static final int THREADS_COUNT = 20;

public static void main(String[] args) {
Thread[] threads = new Thread[THREADS_COUNT];
for (int i = 0; i < THREADS_COUNT; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 1000; i++) {
increase();
}
}
});
threads[i].start();
}

while (Thread.activeCount() > 1) {
Thread.yield();
}

System.out.println(race);
}
}

　　尝试去看看 incrementAndGet() 方法的源代码。

　　尽管CAS 看起来很美，但是显然这种操作无法涵盖互斥同步的所有使用场景，存在这样一个漏洞：如果一个变量V 初次读取的时候是A 值，并且准备赋值的时候检查它仍然为A 值，那我们就能说它的值没有被其他线程改变过嘛？如果这期间它的值被改为B 后又改为了A ，那CAS操作就误认为它从没有改变过。这个漏洞称为“ABA”问题。但是大部分情况下 ABA 问题不会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步。

　　（3）无同步方案

　　要保证线程安全，不是一定要进行同步，两者没有因果关系。同步时保证共享数据争用时的正确性的手段，如果一个方法本来就不涉及共享数据，那它自然就无须任何同步措施去保证正确性，因此会有些代码天生就是线程安全的。

　　可重入代码（Reentrant Code）：可重入代码有一些共同特征，例如不依赖存储在堆上的数据和共用的系统资源、用到的状态量都是由参数中传入、不调用非可重入的方法等。如果一个方法，它的返回结果是可以预测的，只要输入了相同的数据，就能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。

　　线程本地存储（Thread Local Storage）：如果一段代码中需要的数据必须与其他代码共享，那就看看这些数据的代码是否能保证在同一个线程中执行？如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内，这样，无需同步也能保证线程之间不出现数据争用的问题。

　　Java 语言中，如果一个变量要被多线程访问，可以使用 volatile 关键字声明它为“易变得”；如果一个变量要被某个线程独享，可以通过 java.lang.ThreadLocal 类来实现线程本地存储的功能。每一个线程的Thread 对象中都有一个 ThreadLocalMap 对象，这个对象存储了一组以ThreadLocal.threadLocalHashCode 为键，以本地线程变量为值的 K-V 对，

 

三.锁优化

　　高效并发是 JDK 升级的一个重要改进，HotSpot 虚拟机开发团队在这方面花费了大量的经历去实现各种锁优化技术，如 适应性自旋、锁消除、锁粗化、轻量级锁和偏向锁等，这些技术都是为了在线程之间更高效地共享数据，以解决竞争问题，从未提高程序效率。

1.　　自旋锁与自适应自旋

　　前面提到 互斥同步对性能最大的影响即使 阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给了系统的并发性带来了很多压力。虚拟机开发团队注意到，许多共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂机和恢复线程并不值得。如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面的请求锁的那个线程“稍等一下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只需让线程执行一个忙循环（自旋），这项技术即使所谓的自旋锁。

　　自旋等待本身虽然避免了线程切换的开销，但它是占用处理器时间的，因此锁被占用的时间很影响自旋的线程的处理器资源消耗。因此自旋次数默认 10 次（-XX:PreBlockSpin 可以更改自旋次数） 之后，就会使用传统的方式去挂起线程。

　　在JDK1.6 之后引入了自适应的自旋锁，自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

 

2.　　锁消除

　　锁消除是指虚拟机即使编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在功效数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把他们当做栈上数据对待，认为他们是线程私有的，同步加锁自然就无须进行。

　　下面的例子讲个 看似没有同步的代码 实际使用了同步。

public String concatString(String s1, String s2, String s3) {
return s1 + s2 + s3;
}

　　我们知道，由于String 是一个不可变的类，对字符串的连接操作总是通过生成新的String 对象来进行。在JDK 1.5之前， 会转化为StringBuffer 对象的连续 append() 操作，在JDK1.5 之后，会转化为 StringBuilder 对象的连续 append() 操作。即如下代码：

public String concatString(String s1, String s2, String s3) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
sb.append(s3);
return sb.toString();
}

　　现在大家还认为这段代码没有涉及同步吗？每个 StringBUffer.append() 方法中都有一个同步块，锁就是sb 对象。

 

3.　　粗化锁

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

　　但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作时出现的循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。

　　例如上面代码连续的 append（） 方法就属于这类情况，如果虚拟机探测到这样一串零碎的操作都是对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，就是扩展到第一个append（）操作之前 直至最后一个append（） 操作之后，这样只需要加锁一次就可以了。

 

4.轻量级锁

　　要理解轻量级锁，以及后面降到的偏向锁的原理和运作过程，必须从HotSpot 虚拟机的对象（对象头部分 Mark Word）的内存布局开始介绍。例如，在32位的hotSpot虚拟机中对象未被锁定的状态下，Mark Word 的32bit 空间中的 25bit 用于存储对象哈希码（HashCode），4bit 用于存储对象分代年龄，2bit 用于存储锁标志位， 1bit 固定为0，在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容见下表：

存储内容	标志位	状态
对象哈希码、对象分代年龄	01	未锁定
指向锁记录的指针	00	轻量级锁定
指向重量级锁的指针	10	膨胀（重量级锁定）
空，不需要记录信息	11	GC标记
偏向线程ID、偏向时间戳、对象分代年龄	01	可偏向

　　锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。JDK 1.6中默认是开启偏向锁和轻量级锁的，我们也可以通过-XX:-UseBiasedLocking来禁用偏向锁。锁的状态保存在对象的头文件中，以32位的JDK为例：

锁状态	25 bit	4bit	1bit	2bit
23bit	2bit	是否是偏向锁	锁标志位
轻量级锁	指向栈中锁记录的指针	00
重量级锁	指向互斥量（重量级锁）的指针	10
GC标记	空	11
偏向锁	线程ID	Epoch	对象分代年龄	1	01
无锁	对象的hashCode	对象分代年龄	0	01

 

1、轻量级锁的加锁过程

　　（1）在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。这时候线程堆栈与对象头的状态如图2.1所示。

　　（2）拷贝对象头中的Mark Word复制到锁记录中。

　　（3）拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤（3），否则执行步骤（4）。

　　（4）如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图2.2所示。

　　（5）如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。 而当前线程便尝试使用自旋来获取锁，自旋就是为了不让线程阻塞，而采用循环去获取锁的过程。

 

                     图2.1 轻量级锁CAS操作之前堆栈与对象的状态

　　 

                      图2.2 轻量级锁CAS操作之后堆栈与对象的状态

2、轻量级锁的解锁过程：

　　（1）通过CAS操作尝试把线程中复制的Displaced Mark Word对象替换当前的Mark Word。

　　（2）如果替换成功，整个同步过程就完成了。

　　（3）如果替换失败，说明有其他线程尝试过获取该锁（此时锁已膨胀），那就要在释放锁的同时，唤醒被挂起的线程。

三、偏向锁

　　引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。上面说过，轻量级锁是为了在线程交替执行同步块时提高性能，而偏向锁则是在只有一个线程执行同步块时进一步提高性能。

1、偏向锁获取过程：

　　（1）访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01——确认为可偏向状态。

　　（2）如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤（5），否则进入步骤（3）。

　　（3）如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行（5）；如果竞争失败，执行（4）。

　　（4）如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。

　　（5）执行同步代码。

2、偏向锁的释放：

　　偏向锁的撤销在上述第四步骤中有提到。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为“01”）或轻量级锁（标志位为“00”）的状态。

3、重量级锁、轻量级锁和偏向锁之间转换

 

                                        图 2.3三者的转换图

　　该图主要是对上述内容的总结，如果对上述内容有较好的了解的话，该图应该很容易看懂。

 

 《深入理解JAVA虚拟机》的阅读就此结束了