深入理解JVM(7)——线程安全和锁优化

Java中的线程安全

按照线程安全的“安全程度”由强至弱来排序，可以将Java语中各种操作共享的数据分为以下5类：不可变、 绝对线程安全、 相对线程安全、 线程兼容和线程对立。

1.不可变

不变的对象绝对是线程安全的，不需要线程同步，如String、Long、BigInteger。

2.绝对线程安全

对象自身做了 足够的内部同步，也不需要外部同步，如 Random 、ConcurrentHashMap、Concurrent集合、atomic。就是通常讲的线程安全。

3.相对的线程安全

对象的部分方法可以无条件安全使用，但是有些方法需要外部同步，需要Collections.synchronized；有条件线程安全的最常见的例子是遍历由 Hashtable 或者 Vector 或者返回的迭代器。就是通常讲的线程不安全。

4.非线程安全(线程兼容)

对象本身不提供线程安全机制，但是通过外部同步，可以在并发环境使用， 如ArrayList HashMap。

5.线程对立

即使外部进行了同步调用，也不能保证线程安全，这种情况非常少，如如System.setOut()、System.runFinalizersOnExit()。

线程安全的实现

互斥同步

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

在执行 monitorenter 指令时，先尝试获取对象的锁。 如果这个对象没被锁定，或者当前线程已经拥有了那个对象的锁，把锁的计数器加1，在执行 monitorexit 指令时会将锁计数器减1，当计数器为0时，锁就被释放。 如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另外一个线程释放为止。

synchronized 同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题。 其次，同步块在已进入的线程执行完之前，会阻塞后面其他线程的进入。 因为阻塞或唤醒一个线程，都需要从用户态转换到核心态中，因此状态转换需要耗费很多的处理器时间。所以 synchronized 是 Java 语言中一个重量级（Heavyweight）的操作。虚拟机本身也会进行一些优化，譬如在通知操作系统阻塞线程之前加入一段自旋等待过程，避免频繁地切入到核心态之中。

除了 synchronized 之外，还可以使用 java.util.concurrent 包中的重入锁（ReentrantLock）来实现同步。在基本用法上，ReentrantLock 与 synchronized 很相似，他们都具备一样的线程重入特性，只是代码写法上有点区别，一个表现为API层面的互斥锁（lock（）和unlock（）方法配合try/finally语句块来完成），另一个表现为原生语法层面的互斥锁。 不过，相比synchronized,ReentrantLock增加了一些高级功能，主要有以下3项：等待可中断、 可实现公平锁，以及锁可以绑定多个条件。

等待可中断是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情，可中断特性对处理执行时间非常长的同步块很有帮助。

公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized 中的锁是非公平的，ReentrantLock 默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁。

锁绑定多个条件是指一个 ReentrantLock 对象可以同时绑定多个 Condition 对象，而在 synchronized 中，锁对象的 wait（）和 notify（）或 notifyAll（）方法可以实现一个隐含的条件，如果要和多于一个的条件关联的时候，就不得不额外地添加一个锁，而 ReentrantLock 则无须这样做，只需要多次调用 newCondition（）方法即可。

在 synchronized 能实现需求的情况下，优先考虑使用 synchronized 来进行同步。

非阻塞同步

互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步（Blocking Synchronization）。 从处理问题的方式上说，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享数据是否真的会出现竞争，它都要进行加锁、 用户态核心态转换、 维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。 随着硬件指令集的发展，我们有了另外一个选择：基于冲突检测的乐观并发策略，通俗地说，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采取其他的补偿措施，这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步（Non-Blocking Synchronization）。

我们需要操作和冲突检测这两个步骤具备原子性，只能靠硬件来完成这件事情，硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成，这类指令常用的有：

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

CAS指令需要有3个操作数，分别是内存位置（在Java中可以简单理解为变量的内存地址，用V表示）、 旧的预期值（用A表示）和新值（用B表示）。 CAS指令执行时，当且仅当V符合旧预期值A时，处理器用新值B更新V的值，否则它就不执行更新，但是无论是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作。

一般只能通过 Java API 来间接使用 CAS 操作，如 java.util.concurrent 包里面的整数原子类（AtomicInteger、AtomicLong...），其中的compareAndSet() 和 getAndIncrement() 等方法都使用了Unsafe类的CAS操作。 把以前的 变量自增形式由 int i; i++; 改成 AtomicInteger i； i.getAndIncrement(),就可以保证多线程下对i自增操作的正确。

无同步方案

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

可重入代码（Reentrant Code）：

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

线程本地存储（Thread Local Storage）：

如果一段代码中所需要的数据必须与其他代码共享，同时这些代码保证在同一个线程中执行，就可以把共享数据的可见范围限制在同一个线程之内，这样无须同步也能保证线程之间不出现数据争用的问题。

Java 语言中，如果一个变量要被多线程访问，可以使用volatile关键字声明它为“易变的”；如果一个变量要被某个线程独享，Java中就没有这样的关键字来声明，不过可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。 每一个线程的Thread对象中都有一个ThreadLocalMap对象，这个对象存储了一组以ThreadLocal.threadLocalHashCode为键，以本地线程变量为值的K-V值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值，使用这个值就可以在线程K-V值对中找回对应的本地线程变量。

锁优化

自旋锁和自适应自旋

请求锁的线程不放弃处理器的执行时间，为等待持有锁的线程释放锁而执行一个忙循环（自旋），的项技术就是自旋锁。

自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了。 自旋次数的默认值是10次，用户可以使用参数 -XX：PreBlockSpin 来更改。

在JDK 1.6中引入了自适应的自旋锁。 自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。 如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间，比如100个循环。 另外，如果对于某个锁，自旋很少成功获得过，那在以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。

锁消除

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

有许多同步措施并不是程序员自己加入的。例如由于 String 是一个不可变的类，对字符串的连接操作总是通过生成新的 String 对象来进行的，因此 Javac 编译器会对 String 连接做自动优化。 s1 + s2,会转化为 StringBuilder 对象的连续 append() 操作。每个 StringBuffer.append() 方法中都有一个同步块，锁就是 sb 对象。 虚拟机观察变量sb，很快就会发现它的动态作用域被限制在concatString() 方法内部。 也就是说，sb 的所有引用永远不会“逃逸”到 concatString() 方法之外，其他线程无法访问到它，因此，虽然这里有锁，但是可以被安全地消除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。

锁粗化

如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，这样只需要加锁一次就可以了。扩大了同步块的作用范围，但是极大地减少不必要的性能损耗。

轻量级锁

轻量级锁是相对于使用操作系统互斥量来实现的传统锁而言的。 轻量级锁并不是用来代替重量级锁的，其意在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。轻量级锁所适应的场景是线程交替执行同步块的情况，如果存在同一时间访问同一锁的情况，就会导致轻量级锁膨胀为重量级锁。

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三者的转换图

对比

JDk中采用轻量级锁和偏向锁等对Synchronized的优化，但是这两种锁也不是完全没缺点的，比如竞争比较激烈的时候，不但无法提升效率，反而会降低效率，因为多了一个锁升级的过程，这个时候就需要通过-XX:-UseBiasedLocking来禁用偏向锁。下面是这几种锁的对比：

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