深入理解Java虚拟机—线程安全与锁优化

上一篇：深入理解Java虚拟机—Java内存模型与线程

线程安全与锁优化

一 概述

二. 线程安全

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

这个定义比较严谨，它要求线程安全的代码必须具备一个特征：代码本身封装了所有必要的正确性保障手段，令调用者无需关心多线程的问题，更无需自己采取任何措施来保证多线程的正确调用

1. Java语言中的线程安全

1.1 不可变

在Java语言中不可变的对象一定是线程安全的，无论是对象的方法实现还是方的调用者，都不需要再采用任何的线程安全保障措施。如final关键字，只要一个不可变对象被正确构建出来（没有发生this引用逃逸，即对象还未构造完成this引用就被发布出去了），那其外部的可见状态永远不会发生改变，永远不会看到它在多个线程之中处于不一致的状态

• 如果数据是基本数据类型，只要是final修饰，就不可变。
• 如果是对象，那么就需要保证其行为不会对状态产生任何影响。比如String的substring、replace、concat都不会影响它的值，只会返回一个新构造的字符串对象
• Java API中符合不可变要求的类型：java.lang.String/java.lang.Number部分子类等

1.2 绝对线程安全

• 在java API中标注自己是线程安全的类，大多数都不是绝对的线程安全
• java.util.Vector 是一个线程安全的容器，因为它的add()方法，get()方法，size() 方法 这些方法都是被 synchronized修饰的，尽管效率低下，但确实是安全的；对Vector的测试如下：

package com.jvm.thread;

import java.util.Vector;

public class VectorTest {
    private static Vector<Integer> vector = new Vector<>();
    
    public static void main(String[] args) throws InterruptedException {
        while (true) {
            for(int i = 0; i < 10; i++){
                vector.add(i);
            }
            
            Thread removeThread = new Thread(new Runnable() {
                public void run() {
                    for(int i = 0; i < vector.size(); i++){
                        vector.remove(i);
                    }
                }
            });
            
            Thread printThread = new Thread(new Runnable() {
                public void run() {
                    for(int i = 0; i < vector.size(); i++){
                        try {
                            Thread.sleep(1000);
                        } catch (InterruptedException e) {
                            // TODO Auto-generated catch block
                            e.printStackTrace();
                        }
                        System.out.println(vector.get(i));
                    }
                }
            });
            
            removeThread.start();
            printThread.start();
        }
    }
}

对以上代码的分析（Analysis）：

a）运行结果： 作者说会抛出异常（但我的运行结果却没有抛出异常），按理说应该是会抛出异常的；
b）抛出异常的原因：因为如果另一个线程恰好在错误的时间里删除了一个元素，导致序号i 已经不再可用的话，再用i 访问数组就会抛出一个 ArrayIndexOutOfBoundsException。
c）如果要保证这段代码能够正确执行下去，修改后的代码为：

// 对线程安全的容器 Vector的测试(修改后的代码)
public class ModifiedVectorTest {
    private static Vector<Integer> vector = new Vector<>(); 
    
    public static void main(String[] args) {
        while(true) {
            for (int i = 0; i < 100; i++) {
                vector.add(i);
            }
            
            Thread removeThread = new Thread(new Runnable() {
                @Override
                public void run() {
                    synchronized (vector) { // 添加同步块，this line
                        for (int i = 0; i < vector.size(); i++) {
                            vector.remove(i);
                        }
                    }
                }
            });
            
            Thread printThread = new Thread(new Runnable() {
                @Override
                public void run() {
                    synchronized (vector) { // 添加同步块，this line
                        for (int i = 0; i < vector.size(); i++) {
                            System.out.println(vector.get(i));
                        }
                    }
                }
            });
            
            removeThread.start();
            printThread.start();
            
            // 不要同时产生过多的线程，否则会导致os 假死
            while(Thread.activeCount() > 20);
        }
    }
}

1.3 相对线程安全

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

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

1.4 线程兼容

线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端使用正确同步手段来保证对象在并发环境中可以安全地使用，平常说一个类不是线程安全地，绝大多数属于这种情况。JavaAPI中大部分类都是线程兼容地，与Vector和HashTable对应的有ArrayList和HashMap等。

1.5 线程对立

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

比如Thread类的suspend和resume，如果两个线程同时持有一个线程对象，一个中断一个恢复，如果并发进行的话，无论调用是否进行同步，目标线程都有死锁风险。如果suspend一个正要resume的线程，肯定要产生死锁。正是由于这个原因，这两个方法已经废弃。常见的还有System.setIn、System.setOut、System.runFinalizersOnExit等。

2. 线程安全的实现方法

实现线程安全与代码编写有很大关系，但虚拟机提供的同步和锁机制也起到了很大的作用。这里会着重介绍虚拟机如何实现同步和锁，次要介绍如何编写实现线程安全。

2.1 互斥同步

互斥同步（Mutual Exclusion & Synchronization）是常见的一种并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个（或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量（MuTex）和信号量（Semaphore）都是主要的互斥实现方式。因此，在这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。

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

虚拟机规范要求，在执行monitorenter指令时，首先尝试获取对象的锁。如果对象没有被锁定或者当前线程已经拥有了那么对象的锁，把锁的计数器加1，执行monitorexit时，将锁计数减1，当锁计数器为0时，锁被释放。如果获取对象锁失败，当前线程将阻塞等待

虚拟机对monitorenter和monitorexit行为描述中，注意两点：synchronized同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题；同步块在已进入线程执行完之前，会阻塞后面其他线程的进入

还可以使用java.util.concurrent（以下称JUC）包中的重入锁（ReentrantLock）来实现同步。相比synchronized，ReentrantLock增加了一些高级功能，主要以下3项：等待可中断、可实现公平锁，以及锁可以绑定多个条件

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

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

绑定多个条件：一个ReentrantLock对象可以同时绑定多个Condition对象，而synchronized中，锁对象的wait()和notify()或notifyAll()可以实现一个隐含的条件，如果要和多于一个的条件关联时，就不得不额外添加一个锁，而ReentrantLock则无须这样，只要多次调用newCondition()即可

对上图的分析（Analysis）：

A1）多线程环境下 synchronized的吞吐量下降得非常严重，而 ReentrantLock 则能基本保持在同一个比较稳定的水平上；与其说ReentrantLock性能好，还不如说 synchronized还有非常大的优化余地；

A2）虚拟机在未来的性能改进中肯定也会更加偏向于原生的 synchronized，所以还是提倡在 synchronized能实现需求的情况下，优先考虑使用 synchronized 来进行同步；（同步方式推荐使用synchronized）

2.2 非阻塞同步

阻塞同步（互斥同步）的问题：就是进行线程阻塞和唤醒所带来的性能问题，互斥同步属于一种悲观的并发策略，无论共享数据是否真的会出现竞争，它都要进行加锁，用户态核心态转换，维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作；
非阻塞同步定义：基于冲突检测的乐观并发策略，通俗的说，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采用其他的补偿措施，这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为 非阻塞同步

2.2.1 为什么作者要说使用乐观并发策略需要“硬件指令集的发展”才能进行呢？因为 我们需要操作和冲突检测这两个步骤具备原子性，靠什么来保证呢？

硬件：保证一个从语义上看起来需要多次操作的行为只通过一次处理器指令就能完成，这类指令常用的有：（instructions）

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

2.2.2 如何使用CAS 操作来避免阻塞同步，看个荔枝：（测试incrementAndGet 方法的原子性）

// Atomic 变量自增运算测试(incrementAndGet 方法的原子性)
public class AtomicTest {
    public static AtomicInteger race = new AtomicInteger(0);
    
    public static void increase() {
        // 输出正确结果，一切都要归功于 incrementAndGet 方法的原子性
        race.incrementAndGet();  
    }
    
    public static final int THREADS_COUNT = 20;
    
    public static void main(String[] args) throws Exception {
        Thread[] threads = new Thread[THREADS_COUNT];
        for (int i = 0; i < threads.length; i++) {
            threads[i] = new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int j = 0; j < 10000; j++) {
                        increase();
                    }
                }
            });
            threads[i].start();
        }
        
        while(Thread.activeCount() > 1) {
            Thread.yield();
        }
        
        System.out.println(race);
    }
    
    /**
     * incrementAndGet() 方法的JDK 源码
     * Atomically increment by one the current value.
     * @return the updated value
     */
    public final int incrementAndGet() {
        for(;;) {
            int current = get();
            int next = current + 1;
            if(compareAndSet(current,next)) {
                return next;
            }
        }
    }
}

CAS操作（比较并交换操作）的ABA问题：如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就说它的值没有被其他线程改变过了吗？ 如果在这段期间它的值曾经被改为了B，之后又改回了A，那CAS操作就会误认为它从来没有被改变过，这个漏洞称为 CAS操作的 ABA问题；
解决方法：J.U.C 包为了解决这个问题，提供了一个带有标记的原子引用 “AtomicStampedReference”，它可以通过控制变量值的version 来保证CAS的正确性。不过目前来说这个类比较鸡肋， 大部分cases 下 ABA问题 不会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更高效；

2.3 无同步方案

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

• 可重入代码（Reentrant Code）：这种代码也叫纯代码（Pure Code），可以在代码执行的任何时刻中断它，转而去执行另外一断代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误。所有可重入代码都是线程安全的。可重入代码有一些共同特征，例如不依赖存储在堆上的数据和公用的系统资源、用到的状态量都是由参数中传入、不调用非可重入的方法等。判断代码具备可重入的简单原则：如果一个方法，它的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，就满足可重入性的要求，当然也是线程安全的。

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

符合这种特点的应用：大部分使用消费队列的架构模式（如“生产者-消费者”模式）都会讲消费过程尽量在一个线程中消费完；经典Web交互模型中的“一个请求对应一个服务线程”（Thread-per-Request）的处理方式，这种处理方式的广泛应用使得很多Web服务端应用都可以使用线程本地存储来解决线程安全问题。

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

三. 锁优化

1. 自旋锁和自适应锁

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

自旋锁定义：为了让线程等待，我们只需让线程执行一个忙循环（自旋），这项技术就是所谓的自旋

• jdk1.6中 自旋锁是默认开启的，可以使用 -XX:+UseSpinning 参数来开启
• 自旋等待的时间必须要有一定的限度： 如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了。自旋次数的默认值是10，用户可以用参数 -XX:PreBlockSpin 来更改
• 自适应自旋锁：jdk1.6 中引入了自适应的自旋锁。自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定
• 如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间，比如100个cycle；
• 如果对于某个锁，自旋很少成功获得过， 那在以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源；

2. 锁消除

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

许多同步措施并不是程序员自己加入的，同步的代码在Java程序中的普遍程度也许超过我们的想象

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

由于String是一个不可变类，对字符串的连接操作总是通过生成新的String对象来进行，因此Javac编译器会对String连接做自动优化。在JDK1.5前，会转换为StringBuffer对象的append()操作，在JDK1.5及以后版本，会转换为StringBuilder对象的连续append()操作。上段代码可能会变成下面的样子：

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

每个StringBuilder.append()中都有一个同步块，锁是sb对象。虚拟机观察变量sb，很快就会发现它的动态作用域被限制在concatString()的内部。也就是sb的所有引用永远不会“逃逸”到concatString()外，其他线程无法访问到它，所以虽然这里有锁，但是可以被安全地消除掉，在即时编译后，这段代码会忽略所有的同步而直接执行

3. 锁粗化

锁粗化的定义：如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部

大部分情况下，我们在编写代码时，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域才进行同步，如果存在锁竞争，那等待锁的线程也可能尽快拿到锁。

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

// javac 转化后的字符串连接操作
    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();
    }

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

4. 轻量级锁

重量级锁定义：使用操作系统互斥量来实现的传统锁

轻量级锁是JJDK1.6中加入的新型锁机制。轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统重量级锁使用操作系统互斥量产生的性能消耗。

轻量级锁的目的：是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗

轻量级锁提升程序性能的依据是“对于绝大多数的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁比传统锁更慢

HotSpot虚拟机的对象头分为两部分信息

第一部分：用于存储对象自身的运行时数据，如哈希码，GC分代年龄等；这部分数据的长度在32位和64位的虚拟机中分别为 32bit 和 64bit，官方称它为 Mark Word，它是实现轻量级锁和偏向锁的关键
第二部分：用于存储指向方法区对象类型数据的指针，如果是数组对象的话，还会有一个额外的部分用于存储数组长度
对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会工具对象的状态复用自己的存储空间
HotSpot 虚拟机对象头Mark Word 如下图所示：

轻量级锁的加锁过程:

1. 如果此同步对象没有被锁定（锁标志位为01状态）：虚拟机首先将在当前线程的栈帧中建立一个名为 锁记录的空间，用于存储对象目前的Mark Word 的拷贝；
2. 然后，虚拟机将使用CAS 操作尝试将对象的 Mark Word 更新为指向 Lock Record的指针；
3. 如果这个更新工作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位将转变为 00，即表示 此对象处于轻量级锁定状态；
4. 如果这个更新失败了，虚拟机首先会检查对象的Mark Word 是否指向当前线程的栈帧，如果只说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明这个锁对象以及被其他线程抢占了。如果有两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁，锁标志的状态值变为 10，Mark Word中存储的就是指向重量级（互斥量）的指针，后面等待锁的线程也要进入阻塞状态；

轻量级锁的解锁过程：

1. 如果对象的Mark Word仍然指向着线程的锁记录，那就用CAS 操作把对象当前的Mark Word 和 线程中复制的 Dispatched Mard Word替换回来；
2. 如果替换成功，整个同步过程就over了；
3. 如果替换失败，说明有其他线程尝试过获取该锁，那就要在释放锁的同时，唤醒被挂起的线程；

总结

轻量级锁能提升程序同步性能的依据是： 对于绝大部分的锁，在整个同步周期内都是不存在竞争的
如果没有竞争，轻量级锁使用CAS 操作避免了使用互斥量的开销；但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS 操作，因此在有竞争的case下， 轻量级锁会比传统的重量级锁更慢

5. 偏向锁

偏向锁是JDK1.6引入的锁优化，目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。
偏向锁的定义： 如果说轻量级锁是在无竞争的情况下使用CAS操作消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了

偏向锁的偏： 它的意思是这个锁会偏向于 第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步

偏向锁的原理： 若当前虚拟机启用了偏向锁，那么，当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为01， 即偏向模式；同时使用CAS 操作把获取到这个锁的线程的ID 记录在对象的 Mark Word之中，如果 CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作

当有另一个线程去尝试获取这个锁时，偏向模式就结束了：根据锁对象目前是否处于被锁定的状态， 撤销偏向后恢复到未锁定（标志位为01）或轻量级锁定（标志位为00）的状态，后续的同步操作就如上面介绍的轻量级锁那样执行

• 偏向锁可以提高带有同步但无竞争的程序性能；
• 如果程序中大多数的锁总是被多个不同的线程访问：那偏向模式是多余的