深入理解jvm-synchronized(线程安全的实现)

╰半夏微凉° 2023-05-21 15:13 13阅读 0赞

> 本文为读书笔记  
> [可参考锁的膨胀过程][Link 1]

### 文章目录 ###

*  1. 实现方法-互斥同步(互斥同步属于一种悲观的并发策略)
 *   *  锁优化
     *   *  自旋锁与自适应自旋
         *  锁消除
         *  锁粗化
         *  轻量级锁(无竞争适用)
         *  偏向锁
         *  以上几个锁的优缺点对比
 *  2.实现方法-非阻塞同步
 *  3. 实现方法-无同步方案
 *  4.锁的内存语义
 *   *  锁的释放-获取建立的happens-before关系
     *  锁的释放和获取的内存语义
 *  5. 锁膨胀过程
 *   *  epoch

# 1. 实现方法-互斥同步(互斥同步属于一种悲观的并发策略) #

同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条线程使用。  
互斥是实现同步的一种手段，临界区（CriticalSection）、互斥量（Mutex）和信号量（Semaphore）都是常见的互斥实现方式。  
**互斥是因，同步是果；互斥是方法，同步是目的。**

--------------------

在Java里面，最基本的互斥同步手段就是synchronized关键字:

synchronized关键字经过Javac编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令。

> 在执行monitorenter指令时，首先要去尝试获取对象的锁。如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行monitorexit指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。

持有锁是一个重量级（Heavy-Weight）的操作 ,如果要**阻塞或唤醒一条线程**，则需要操作系统来帮忙完成，这就不可避免地陷入**用户态到核心态的转换**中，进行这种状态转换需要耗费很多的处理器时间。

其次,JUC 包下的ReentrantLock也可以实现(相较于synchronized多了以下特性):

·等待可中断：是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。

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

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

## 锁优化 ##

### 自旋锁与自适应自旋 ###

> 即自旋 (忙)等待获取锁,这样就避免了 等待获取锁获取不到的时候,进入阻塞状态,再之后拿到锁之后进行的上下文切换的性能损耗

可以使用-XX：+UseSpinning参数来开启,JDK 6中就已经改为默认开启了

我们就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

如果锁被占用的时间很短，自旋等待的效果就会非常好，反之如果锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源

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

如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而允许自旋等待持续相对更长的时间，比如持续100次忙循环。另一方面，如果对于某个锁，自旋很少成功获得过锁，那在以后要获取这个锁时将有可能直接省略掉自旋过程，以避免浪费处理器资源。

### 锁消除 ###

锁消除是指虚拟机即时编译器在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。

锁消除的主要判定依据来源于**逃逸分析**的数据支持

逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他地方中，称为方法逃逸。

### 锁粗化 ###

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

例如:

lock a(){...}
    
    b(){
    a();
    a();
    a();
    }
    //那么只会再b()上加一次锁

### 轻量级锁(无竞争适用) ###

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

**预备知识:**  
HotSpot虚拟机的对象头（Object Header）分为两部分，第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄（Generational GC Age）等。这部分数据的长度在32位和64位的Java虚拟机中分别会占用32个或64个比特，官方称它为`“Mark Word”`。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70]  
这部分是实现轻量级锁和偏向锁的关键。

轻量级锁工作介绍:  
在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在**当前线程的栈帧**中建立一个名为锁记录\*\*（Lock Record）**的空间，用于存储锁对象目前的MarkWord的拷贝（官方为这份拷贝加了一个Displaced前缀，即**Displaced Mark Word\*\*）

之后,虚拟机将使用**CAS操作**尝试把对象的**Mark Word更新**为指向**Lock Record**的指针。如果这个更新动作成功了，即**代表该线程拥有了这个对象的锁**，并且对象Mark Word的锁标志位（Mark Word的最后两个比特）将**转变为“00”**，表示此对象处于轻量级锁定状态。

如果这个**更新操作失败**了，那就**意味着至少存在一条线程与当前线程竞争获取该对象的锁**。虚拟机**首先会检查对象的Mark Word是否指向当前线程的栈帧**，如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了，**否则就说明这个锁对象已经被其他线程抢占了**。如果**出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效**，必须要膨胀为重量级锁，锁标志的状态值变为“10”，此时Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也必须进入阻塞状态。

解锁过程也同样是通过CAS操作来进行的,如果对象的Mark Word仍然指向线程的锁记录，那就用CAS操作把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来。假如能够成功替换，那整个同步过程就顺利完成了；

**轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”这一经验法则。**

因此在有竞争的情况下，轻量级锁反而会比传统的重量级锁更慢。

下图是锁竞争导致碰撞的流程图:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 1]

### 偏向锁 ###

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

**它的意思是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。**  
不需要同步指:不需要再去用CAS把对象的MarkWord更新

当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为“01”、把偏向模式设置为“1”，表示**进入偏向模式**。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁、解锁及对Mark Word的更新操作等）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 2]  
有时候使用参数-XX：-UseBiasedLocking来禁止偏向锁优化反而可以提升性能。

### 以上几个锁的优缺点对比 ###

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

# 2.实现方法-非阻塞同步 #

> 基于冲突检测的乐观并发策略，通俗地说就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现没有竞争的共享数据为止。也称为无锁

实现非阻塞同步的硬件提供的原子指令包括:

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

# 3. 实现方法-无同步方案 #

可重入代码（Reentrant Code）:是指可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误，也不会对结果有所影响。

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

(ThreadLocal 实现线程安全),简称空间换时间  
为每一个线程都提供了一份变量的副本,从而实现同时访问而相不干扰

# 4.锁的内存语义 #

## 锁的释放-获取建立的happens-before关系 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 4]  
1）根据程序次序规则，1 happens-before 2, 2 happens-before 3;4 happens-before 5, 5 happens-before 6。

2）根据监视器锁规则，3 happens-before 4。

3）根据happens-before的传递性，2 happens-before 5。

## 锁的释放和获取的内存语义 ##

❑ 线程A释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了（线程A对共享变量所做修改的）消息。

❑ 线程B获取一个锁，实质上是线程B接收了之前某个线程发出的（在释放这个锁之前对共享变量所做修改的）消息。

❑ 线程A释放锁，随后线程B获取这个锁，这个过程实质上是线程A通过主内存向线程B发送消息。

[ReentranLock例子][ReentranLock]

# 5. 锁膨胀过程 #

`偏向锁`只会在第一次请求时采用 CAS 操作，在锁对象的标记字段中记录下当前线程的地址。在之后的运行过程中，持有该偏向锁的线程的加锁操作将直接返回。它针对的是锁仅会被同一线程持有的情况。

`轻量级锁`采用 CAS 操作，将锁对象的标记字段替换为一个指针，指向当前线程栈上的一块空间，存储着锁对象原本的标记字段。它针对的是多个线程在不同时间段申请同一把锁的情况。

`重量级锁`会阻塞、唤醒请求加锁的线程。它针对的是多个线程同时竞争同一把锁的情况。Java 虚拟机采取了自适应自旋，来避免线程在面对非常小的 synchronized 代码块时，仍会被阻塞、唤醒的情况。

偏向锁：  
偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。

在大多数情况下，锁总是由同一线程多次获得，不存在多线程竞争，所以出现了偏向锁。其目标就是在只有一个线程执行同步代码块时能够提高性能。  
当一个线程访问同步代码块并获取锁时，会在Mark Word里存储锁偏向的线程ID。  
在线程进入和退出同步块时不再通过CAS操作来加锁和解锁，而是检测Mark Word里是否存储着指向当前线程的偏向锁。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，**因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令即可。**

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

偏向锁在JDK 6及以后的JVM里是默认启用的。可以通过JVM参数关闭偏向锁：-XX:-UseBiasedLocking=false，关闭之后程序默认会进入轻量级锁状态。

轻量级锁:

当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。

在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，然后拷贝对象头中的Mark Word复制到锁记录中。

拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock Record里的owner指针指向对象的Mark Word。

如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，表示此对象处于轻量级锁定状态。  
如果轻量级锁的更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明多个线程竞争锁。

**若当前只有一个等待线程，则该线程通过自旋进行等待。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。**

多个线程在不同的时间段请求同一把锁，也就是说没有锁竞争。针对这种情形，Java 虚拟机采用了轻量级锁，来避免重量级锁的阻塞以及唤醒  
在没有锁竞争的前提下，减少传统锁使用OS互斥量产生的性能损耗  
在竞争激烈时，轻量级锁会多做很多额外操作，导致性能下降  
可以认为两个线程交替执行的情况下请求同一把锁

重量级锁：

多个线程竞争同一个锁的时候，虚拟机会阻塞加锁失败的线程，并且在目标锁被释放的时候，唤醒这些线程；  
Java 线程的阻塞以及唤醒，都是依靠操作系统来完成的：os pthread\_mutex\_lock() ；  
升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态

## epoch ##

从偏向锁的撤销讲起。当请求加锁的线程和锁对象标记字段保持的线程地址不匹配时（而且 epoch 值相等，如若不等，那么当前线程可以将该锁重偏向至自己），Java 虚拟机需要撤销该偏向锁。这个撤销过程非常麻烦，它要求持有偏向锁的线程到达安全点，再将偏向锁替换成轻量级锁；

如果某一类锁对象的总撤销数超过了一个阈值（对应 jvm参数 -XX:BiasedLockingBulkRebiasThreshold，默认为 20），那么 Java 虚拟机会宣布这个类的偏向锁失效；（这里说的就是批量重偏向）  
具体的做法便是在每个类中维护一个 epoch 值，你可以理解为第几代偏向锁。当设置偏向锁时，Java 虚拟机需要将该 epoch 值复制到锁对象的标记字段中；  
在宣布某个类的偏向锁失效时，Java 虚拟机实则将该类的 epoch 值加 1，表示之前那一代的偏向锁已经失效。而新设置的偏向锁则需要复制新的 epoch 值；  
为了保证当前持有偏向锁并且已加锁的线程不至于因此丢锁，Java 虚拟机需要遍历所有线程的 Java 栈，找出该类已加锁的实例，并且将它们标记字段中的 epoch 值加 1。该操作需要所有线程处于安全点状态；  
如果总撤销数超过另一个阈值（对应 jvm 参数 -XX:BiasedLockingBulkRevokeThreshold，默认值为 40），那么 Java 虚拟机会认为这个类已经不再适合偏向锁。此时，Java 虚拟机会撤销该类实例的偏向锁，并且在之后的加锁过程中直接为该类实例设置轻量级锁(这里说的就是偏向批量撤销)

[Link 1]: https://www.cnblogs.com/yuhangwang/p/11295940.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70]: /images/20230521/c8c7dfdd732a44a284a85d41f7aae352.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 1]: /images/20230521/1d1efbc32e984acba494fb0b3b0bb342.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 2]: /images/20230521/d36c6935880a4c74af1ad394e998c108.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 3]: /images/20230521/c7edca250612418eac38ad28fffea17c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 4]: /images/20230521/0c3fba22d63646188ec64022a5eeaf68.png
[ReentranLock]: https://blog.csdn.net/littlewhitevg/article/details/105584195