【2023】java多线程——锁的使用及分类

﹏ヽ暗。殇╰゛Y 2023-10-13 11:22 4阅读 0赞

#### 锁简介 ####

**java多线程的锁都是基于对象的**，每个对象都可以作为一个锁。类锁也是对象锁

java6以后，一个对象分为了4种锁的状态，级别由低到高依次是：

1.  无锁状态
2.  偏向锁状态
3.  轻量级锁状态
4.  重量级锁状态

#### java对象头 ####

每个Java对象都有对象头。如果是非数组类型，则用2个字宽来存储对象头，如果是数组，则会用3个字宽来存储对象头。在32位处理器中，一个字宽是32位；在64位虚拟机中，一个字宽是64位。对象头的内容如下表：

<table> 
 <thead> 
  <tr> 
   <th>长度</th> 
   <th>内容</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>32/64bit</td> 
   <td>Mark Word</td> 
   <td>存储对象的hashCode或锁信息等</td> 
  </tr> 
  <tr> 
   <td>32/64bit</td> 
   <td>Class Metadata Address</td> 
   <td>存储到对象类型数据的指针</td> 
  </tr> 
  <tr> 
   <td>32/64bit</td> 
   <td>Array length</td> 
   <td>数组的长度（如果是数组）</td> 
  </tr> 
 </tbody> 
</table>

我们主要来看看Mark Word的格式：

<table> 
 <thead> 
  <tr> 
   <th>锁状态</th> 
   <th>29 bit 或 61 bit</th> 
   <th>1 bit 是否是偏向锁？</th> 
   <th>2 bit 锁标志位</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>无锁</td> 
   <td></td> 
   <td>0</td> 
   <td>01</td> 
  </tr> 
  <tr> 
   <td>偏向锁</td> 
   <td>线程ID</td> 
   <td>1</td> 
   <td>01</td> 
  </tr> 
  <tr> 
   <td>轻量级锁</td> 
   <td>指向栈中锁记录的指针</td> 
   <td>此时这一位不用于标识偏向锁</td> 
   <td>00</td> 
  </tr> 
  <tr> 
   <td>重量级锁</td> 
   <td>指向互斥量（重量级锁）的指针</td> 
   <td>此时这一位不用于标识偏向锁</td> 
   <td>10</td> 
  </tr> 
  <tr> 
   <td>GC标记</td> 
   <td></td> 
   <td>此时这一位不用于标识偏向锁</td> 
   <td>11</td> 
  </tr> 
 </tbody> 
</table>

可以看到，当对象状态为偏向锁时，`Mark Word`存储的是偏向的线程ID；当状态为轻量级锁时，`Mark Word`存储的是指向线程栈中`Lock Record`的指针；当状态为重量级锁时，`Mark Word`为指向堆中的monitor对象的指针。

#### 1、偏向锁： ####

Hotspot的作者经过以往的研究发现大多数情况下**锁不仅不存在多线程竞争，而且总是由同一线程多次获得**，于是引入了偏向锁。

偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他的线程访问，则持有偏向锁的线程将永远不需要触发同步。也就是说，**偏向锁在资源无竞争情况下消除了同步语句，连CAS操作都不做了，提高了程序的运行性能。**

> 就是对锁置个变量，如果发现为true，代表资源无竞争，则无需再走各种加锁/解锁流程。如果为false，代表有其他线程竞争资源，那么走后面的流程。

**实现原理：**

一个线程在第一次进入同步块时，会在对象头和栈帧中的锁记录里存储锁的偏向的线程ID。当下次该线程进入这个同步块时，会去检查锁的Mark Word里面是不是放的自己的线程ID。

如果是，表明该线程已经获得了锁，以后该线程在进入和退出同步块时不需要花费CAS操作来加锁和解锁 ；如果不是，就代表有另一个线程来竞争这个偏向锁。这个时候会尝试使用CAS来替换Mark Word里面的线程ID为新线程的ID，这个时候要分两种情况：

*  成功，表示之前的线程不存在了，Mark Word里面的线程ID为新线程的ID，锁不会升级，仍然为偏向锁；
 *  失败，表示之前的线程仍然存在，那么暂停之前的线程，设置偏向锁标识为0，并设置锁标志位为00，升级为轻量级锁，会按照轻量级锁的方式进行竞争锁。

> CAS：Compare and Swap.
> 
> 比较并设置。用于在硬件层面上提供原子性操作。在 Intel 处理器中，比较并交换通过指令cmpxchg实现。 比较是否和给定的数值一致，如果一致则修改，不一致则不修改。

过程：

![在这里插入图片描述][69f454ad7cc54b618533a3bab606e49f.png]

#### 2、轻量级锁 ####

多个线程在不同时段获取同一把锁，即在不存在锁竞争的情况下，也就没有线程阻塞。针对这种情况，JVM采用轻量级锁来避免线程的阻塞与唤醒。

**轻量级锁释放：**

在释放锁时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。

![在这里插入图片描述][a28e170d1b5c416fa61d6c63a1f6cd7a.png]

#### 3、重量级锁 ####

重量级锁依赖于操作系统的互斥量（mutex） 实现的，而操作系统中线程间状态的转换需要相对比较长的时间，所以重量级锁效率很低，但被阻塞的线程不会消耗CPU。

前面说到，每一个对象都可以当做一个锁，当多个线程同时请求某个对象锁时，对象锁会设置几种状态用来区分请求的线程：

Contention List：所有请求锁的线程将被首先放置到该竞争队列
    Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List
    Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set
    OnDeck：任何时刻最多只能有一个线程正在竞争锁，该线程称为OnDeck
    Owner：获得锁的线程称为Owner
    !Owner：释放锁的线程

#### 锁的升级流程 ####

每一个线程在准备获取共享资源时：

*  第一步，检查MarkWord里面是不是放的自己的ThreadId ,如果是，表示当前线程是处于 “偏向锁” 。
 *  第二步，如果MarkWord不是自己的ThreadId，锁升级，这时候，用CAS来执行切换，新的线程根据MarkWord里面现有的ThreadId，通知之前线程暂停，之前线程将Markword的内容置为空。
 *  第三步，两个线程都把锁对象的HashCode复制到自己新建的用于存储锁的记录空间，接着开始通过CAS操作， 把锁对象的MarKword的内容修改为自己新建的记录空间的地址的方式竞争MarkWord。
 *  第四步，第三步中成功执行CAS的获得资源，失败的则进入自旋 。
 *  第五步，自旋的线程在自旋过程中，成功获得资源(即之前获的资源的线程执行完成并释放了共享资源)，则整个状态依然处于 轻量级锁的状态，如果自旋失败 。
 *  第六步，进入重量级锁的状态，这个时候，自旋的线程进行阻塞，等待之前线程执行完成并唤醒自己。

## 锁的分类 ##

#### 一、分类 ####

#### 1、可重入锁和非可重入锁 ####

所谓重入锁，顾名思义。就是支持重新进入的锁，也就是说这个锁支持一个线程对资源重复加锁。

synchronized关键字就是使用的重入锁。比如说，你在一个synchronized实例方法里面调用另一个本实例的synchronized实例方法，它可以重新进入这个锁，不好出现任何异常。

如果我们自己在继承AQS实现同步器的时候，没有考虑到占有锁的线程再次获取锁的场景，可能就会导致线程阻塞，那这个就是一个“非可重入锁”。

`ReentrantLock`的中文意思就是可重入锁。也是本文后续要介绍的重点类。

#### 2、公平锁与非公平锁 ####

这里的“公平”，其实通俗意义来说就是“先来后到”，也就是FIFO。如果对一个锁来说，先对锁获取请求的线程一定会先被满足，后对锁获取请求的线程后被满足，那这个锁就是公平的。反之，那就是不公平的。

一般情况下，**非公平锁能提升一定的效率。但是非公平锁可能会发生线程饥饿（有一些线程长时间得不到锁）的情况**。所以要根据实际的需求来选择非公平锁和公平锁。

ReentrantLock支持非公平锁和公平锁两种。

#### 3、读写锁和排它锁 ####

我们前面讲到的synchronized用的锁和ReentrantLock，其实都是“排它锁”。也就是说，这些锁在同一时刻只允许一个线程进行访问。

而读写锁可以在同一时刻允许多个读线程访问。Java提供了ReentrantReadWriteLock类作为读写锁的默认实现，内部维护了两个锁：一个读锁，一个写锁。通过分离读锁和写锁，使得在“读多写少”的环境下，大大地提高了性能。

> 注意，即使用读写锁，在写线程访问时，所有的读线程和其它写线程均被阻塞。

**可见，只是synchronized是远远不能满足多样化的业务对锁的要求的**。接下来我们介绍一下JDK中有关锁的一些接口和类。

#### 4、乐观锁和悲观锁 ####

*  乐观锁：
    
     *  乐观锁是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新时会判断此期间数据是否被更新
     *  采取在写时先读出当前版本号，然后加锁操作(比较跟上一次的版本号，如果一样则更新)，如果失败则要重复读-比较-写的操作
     *  java 中的乐观锁基本通过 CAS 操作实现的，CAS 是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败
 *  悲观锁：
    
     *  悲观锁是就是悲观思想，即认为写多，遇到并发写的可能性高，每次去拿数据的时候都认为别人会修改，所以每次在读写数据的时候都会上锁，这样别人想读写这个数据就会 block 直到拿到锁Java 中的悲观锁就是Synchronized,AQS 框架下的锁则是先尝试 cas 乐观锁去获取锁，获取不到，
    
    才会转换为悲观锁，如 RetreenLock

#### 二、JDK中有关锁的一些接口和类 ####

JDK中关于并发的类大多都在`java.util.concurrent`

#### 1、抽象类AQS/AQLS/AOS ####

AQS里面的“资源”是用一个`int`类型的数据来表示的，有时候我们的业务需求资源的数量超出了`int`的范围，所以在JDK 1.6 中，多了一个**AQLS**（AbstractQueuedLongSynchronizer）。它的代码跟AQS几乎一样，只是把资源的类型变成了`long`类型。

AQS和AQLS都继承了一个类叫**AOS**（AbstractOwnableSynchronizer）。这个类也是在JDK 1.6 中出现的。这个类只有几行简单的代码。从源码类上的注释可以知道，它是用于表示锁与持有者之间的关系（独占模式）。

#### 2、接口Condition/Lock/ReadWriteLock ####

juc.locks包下共有三个接口：`Condition`、`Lock`、`ReadWriteLock`。其中，Lock和ReadWriteLock从名字就可以看得出来，分别是锁和读写锁的意思。Lock接口里面有一些获取锁和释放锁的方法声明，而ReadWriteLock里面只有两个方法，分别返回“读锁”和“写锁”：

public interface ReadWriteLock {
        
        Lock readLock();
        Lock writeLock();
    }

Lock接口中有一个方法是可以获得一个`Condition`:

Condition newCondition();

每个对象都可以用继承自`Object`的**wait/notify**方法来实现**等待/通知机制**。而Condition接口也提供了类似Object监视器的方法，通过与**Lock**配合来实现等待/通知模式。

那为什么既然有Object的监视器方法了，还要用Condition呢？这里有一个二者简单的对比：

<table> 
 <thead> 
  <tr> 
   <th>对比项</th> 
   <th>Object监视器</th> 
   <th>Condition</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>前置条件</td> 
   <td>获取对象的锁</td> 
   <td>调用Lock.lock获取锁，调用Lock.newCondition获取Condition对象</td> 
  </tr> 
  <tr> 
   <td>调用方式</td> 
   <td>直接调用，比如object.notify()</td> 
   <td>直接调用，比如condition.await()</td> 
  </tr> 
  <tr> 
   <td>等待队列的个数</td> 
   <td>一个</td> 
   <td>多个</td> 
  </tr> 
  <tr> 
   <td>当前线程释放锁进入等待状态</td> 
   <td>支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>当前线程释放锁进入等待状态，在等待状态中不中断</td> 
   <td>不支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>当前线程释放锁并进入超时等待状态</td> 
   <td>支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>当前线程释放锁并进入等待状态直到将来的某个时间</td> 
   <td>不支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>唤醒等待队列中的一个线程</td> 
   <td>支持</td> 
   <td>支持</td> 
  </tr> 
  <tr> 
   <td>唤醒等待队列中的全部线程</td> 
   <td>支持</td> 
   <td>支持</td> 
  </tr> 
 </tbody> 
</table>

#### 3、ReentrantLock ####

ReentrantLock是一个非抽象类，**它是Lock接口的JDK默认实现**，实现了锁的基板功能。从名字上看，它是一个”可重入“锁，从源码上看，它内部有一个抽象类`Sync`，是继承了AQS，自己实现的一个同步器。同时，ReentrantLock内部有两个非抽象类`NonfairSync`和`FairSync`，它们都继承Sync。从名字上看得出，分别是”非公平同步器“和”公平同步器“的意思。这意味着ReentrantLock可以支持”公平锁“和”非公平锁“。

通过看这两个同步器的源码可以发现，它们的实现都是”独占“的。都调用了AOS的`setExclusiveOwnerThread`方法，所以ReentrantLock的锁是”独占“的，也就是说，它的锁都是”排他锁“，不能共享。

在ReentrantLock的构造方法里，可以传入一个`boolean`类型的参数，来指定它是否是一个公平锁，默认情况下是非公平的。这个参数一旦实例化后就不能修改，只能通过`isFair()`方法来查看。

#### 4、**ReentrantReadWriteLock** ####

这个类也是一个非抽象类，\*\*它是ReadWriteLock接口的JDK默认实现。\*\*它与ReentrantLock的功能类似，同样是可重入的，支持非公平锁和公平锁。不同的是，它还支持”读写锁“。

ReentrantReadWriteLock实现了读写锁，但它有一个小弊端，就是在“写”操作的时候，其它线程不能写也不能读。我们称这种现象为“写饥饿”，将在后文的StampedLock类继续讨论这个问题。

#### 5、StampedLock ####

`StampedLock`类是在Java 8 才发布的。它没有实现Lock接口和ReadWriteLock接口，但它其实是实现了“读写锁”的功能，并且性能比ReentrantReadWriteLock更高。StampedLock还把读锁分为了“乐观读锁”和“悲观读锁”两种。

前面提到了ReentrantReadWriteLock会发生“写饥饿”的现象，但StampedLock不会。它是怎么做到的呢？它的核心思想在于，**在读的时候如果发生了写，应该通过重试的方式来获取新的值，而不应该阻塞写操作。这种模式也就是典型的无锁编程思想，和CAS自旋的思想一样**。这种操作方式决定了StampedLock在读线程非常多而写线程非常少的场景下非常适用，同时还避免了写饥饿情况的发生。

[69f454ad7cc54b618533a3bab606e49f.png]: https://img-blog.csdnimg.cn/69f454ad7cc54b618533a3bab606e49f.png
[a28e170d1b5c416fa61d6c63a1f6cd7a.png]: https://img-blog.csdnimg.cn/a28e170d1b5c416fa61d6c63a1f6cd7a.png