深入理解JVM虚拟机（十一）：线程安全与锁优化

妖狐艹你老母 2022-04-03 11:00 283阅读 0赞

# 1. 线程安全 #

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

## 1.1 Java语言中的线程安全 ##

这里讨论的线程安全，就限定于多个线程之间存在共享数据访问的这个前提。

按照线程安全的“安全程度”由强到弱排序，可以把Java中各个操作共享的数据分为以下5类：

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

### 1. 不可变 ###

不可变（Immutable）的对象一定是线程安全的。

如果共享数据是一个基本数据类型，定义时使用final关键字修饰可保证它不可变。

如果共享数据是一个对象，那就需要保证对象的行为不会对其状态产生任何影响才行。其中最简单的是把对象中带有状态的变量都声明为final，这样在构造函数结束后，它就是不可变的。

Java API中符合不可变要求的类型：java.lang.String/java.lang.Number部分子类等。

### 2. 绝对线程安全 ###

绝对线程安全满足线程安全的定义。Java API中标注自己是线程安全的类，大多数时候都不是绝对的线程安全。

### 3. 相对线程安全 ###

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

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

### 4. 线程兼容 ###

线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中安全使用。Java API中大部分类都是线程兼容的。

### 5. 线程对立 ###

是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。通常是有害的，应当尽量避免。

一个线程对立的例子是Thread类的suspend()和resume()方法，如果两个线程同时持有一个线程对象，一个尝试去中断线程，另一个尝试去恢复线程，如果并发进行的话，无论调用是否进行了同步，目标线程都是存在死锁风险的，如果suspend()中断的线程就是即将要执行resume()的那个线程，那就肯定要产生死锁了。正是因为此原因，此两方法已被JDK废弃了。

## 1.2 线程安全的实现方法 ##

### 1.2.1 互斥同步 ###

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

#### synchronized关键字 ####

在Java中，最基本的互斥同步手段是synchronized关键字

synchronized关键字实现原理：

*  synchronized关键字经过编译后，会在同步代码块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果程序中synchronized指明了对象参数，那就是这个对象的reference；如果没有指明，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或Class对象来作为锁对象。
 *  虚拟机规范要求，在执行monitorenter指令时，首先尝试获取对象的锁。如果对象没有被锁定或者当前线程已经拥有了那么对象的锁，把锁的计数器加1，执行monitorexit时，将锁计数减1，当锁计数器为0时，锁被释放。如果获取对象锁失败，当前线程将阻塞等待。

Java中的线程是映射到操作系统的原生线程上的，如果要阻塞或则唤醒一个线程，都需要操作系统来帮忙，这就需要从用户态转换到内核态中，因此状态转换需要耗费絮都CPU处理器的时间。所以说synchronized关键字是一个重量级锁，而虚拟机本身也会进行一些优化，譬如在通知操作系统阻塞线程之前加上一段自旋等待过程，避免频繁地切入到内核态中。

#### 重入锁（ReentrantLock）来实现同步 ####

重入锁（ReentrantLock）代码写法上面会有区别，一个表现为API层面的互斥锁，另一个表现为原生语法层面的互斥锁。

ReentrantLock增加了一些高级功能：

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

### 1.2.2 非阻塞同步 ###

互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步（Blocking Synchronized）。处理问题方式上，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施（例如加锁），那肯定会出现问题，无论共享数据是否真的出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有阻塞的线程需要等待唤醒等操作。

随着硬件指令集的发展，有了另外一种选择：基于冲突检测的乐观并发策略，就是先进性操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步称为非阻塞同步（Non-Blocking Synchronization）。

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

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

### 1.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键值对中找回对应的本地线程变量。

# 2. 锁优化 #

HotSpot虚拟机开发团队在这个版本上花费了大量的精力去实现各种锁优化技术，如适应性自旋、锁消除、锁粗化、轻量级锁、偏向锁。

## 2.1 自旋锁 ##

解决的问题：互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入到内核态中完成，这些操作给系统的并发性能带来了很大的压力。

解决方案：为了让线程等待，我们需要让线程执行一个忙循环（自旋），这项技术就是自旋锁

自旋等待不能代替阻塞，且先不说对处理器量的要求，自旋等待本身虽然避免了线程切换的开销，但它要占用处理器的时间，因此，如果锁被占用的时间短，自旋等待效果好，反之，自旋的线程只会白白消耗处理器资源，而不做任何有用工作，带来性能上的浪费。因此，自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有获得锁，就应当使用传统的方式挂起线程。自旋次数的默认值是10次，用户可以使用参数 -XX:PerBlockSpin 来修改。

## 2.2 自适应的自旋锁 ##

解决自旋锁的问题：由于自旋锁每次选择的时间是固定的，对于系统来说是没有必要的。

JDK1.6引入了自适应的自旋锁。自旋的时间是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就认为这次自旋也很可能成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得，在以后获得这个锁时将可能省略自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确，虚拟机就变得越来越“聪明”了。

## 2.3 锁消除 ##

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

许多同步措施并不是程序员自己加入的，同步的代码在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()外，其他线程无法访问到它，所以虽然这里有锁，但是可以被安全地消除掉，在即时编译后，这段代码会忽略所有的同步而直接执行。

## 2.4 锁粗化 ##

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

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

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

## 2.5 轻量级锁 ##

解决问题：由于传统的重量级锁采用操作系统互斥量来实现同步，每次加锁解锁操作都需要从用户态抓换到内核态，这样会给整个系统带来一定的性能消耗。

轻量级锁原理：  
要理解轻量级锁以及偏向锁，则必须从HotSpot虚拟机的对象（对象头）的内存布局开始。HotSpot虚拟机的对象头分为两部分信息，第一部分用于存储对象自身运行时数据，如哈希码（HashCode）、GC分代年龄（GC Age）等，这部分数据的长度在32位和64位的虚拟机中分别为32bit和64bit，官方称为“Mark Word”。另外一部分用于存储指向方法区对象类型数据的指针。在32位的虚拟机中25bit用于存储对象哈希码，4bit存储对象分代年龄，2bit存储锁标志位，其他略。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70]

**实现原理:**

> 1.  在代码进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word）
> 2.  虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位（Mark Word的最后2bit）将转变为“00”，即表示此对象处于轻量级锁定状态
> 3.  如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果只说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其他线程抢占了。

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 1]

轻量级锁提升程序性能的依据是“对于绝大多数的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销。如果有两条以上的线程争用同一个轻量级锁，那轻量级锁就不再有效，要膨胀为重量级锁，锁标志状态变为"10"。

## 2.6 偏向锁 ##

解决问题：轻量级锁在无竞争情况下使用CAS操作，每次加锁解锁操作都需要使用CAS指令原语。这种操作对于只有一个线程访问对象来说，会造成一定的性能开销。

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

**实现原理：**

> 1.  当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为“01”，即偏向模式。 同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中，如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作
> 2.  当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。 根据锁对象目前是否处于被锁定的状态，撤销偏向（Revoke Bias）后恢复到未锁定（标志位为“01”）或轻量级锁定（标志位为“00”）的状态，后续的同步操作就如上面介绍的轻量级锁那样执行

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 2]

偏向锁可以提高带有同步但无竞争的程序性能。它同样是一个带有效益权衡（Trade Off）性质的优化，它对程序运行不一定有利，如果程序中大多数的锁都总是被多个不同的线程访问，那偏向锁局势多余的。在具体问题具体分析的前提下，有时使用参数 -XX:-UseBiasedLocking 来禁止偏向锁优化反而可以提升性能。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70]: /images/20220403/3c030f7682dc4225b0fb157c4546b8c3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 1]: /images/20220403/b38f1028f09f47a29e835749617b0eb1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 2]: /images/20220403/dd5126d099754c6498e5602357517848.png