锁升级的过程

2022-01-18 20:14:11

微信公众号：码工是小希

关注选择“星标”，重磅干货，第一时间送达！

[如果你觉得文章对你有帮助，欢迎关注，再看，转发，点赞]

坚持去思索，就会很酷

为读者介绍主流锁的知识点，以及不同的锁的适用场景。
Java中往往是按照是否含有某一特性来定义锁，我们通过特性将锁进行分组归类，再使用对比的方式进行介绍，帮助大家更快捷的理解相关知识。

锁的分类及其解释

先来个大体的流程图来感受一下这个过程，然后下面我们再分开来说

无锁

无锁状态，无锁即没有对资源进行锁定，所有的线程都可以对同一个资源进行访问，但是只有一个线程能够成功修改资源。

无锁的特点就是在循环内进行修改操作，线程会不断的尝试修改共享资源，直到能够成功修改资源并退出，在此过程中没有出现冲突的发生，这很像我们在之前文章中介绍的 CAS 实现，CAS 的原理和应用就是无锁的实现。无锁无法全面代替有锁，但无锁在某些场合下的性能是非常高的。

偏向锁

HotSpot 的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，还存在锁由同一线程多次获得的情况，偏向锁就是在这种情况下出现的，它的出现是为了解决只有在一个线程执行同步时提高性能。

可以从对象头的分配中看到，偏向锁要比无锁多了线程ID 和 epoch，下面我们就来描述一下偏向锁的获取过程

偏向锁获取过程

首先线程访问同步代码块，会通过检查对象头 Mark Word 的锁标志位判断目前锁的状态，如果是 01，说明就是无锁或者偏向锁，然后再根据是否偏向锁的标示判断是无锁还是偏向锁，如果是无锁情况下，执行下一步
线程使用 CAS 操作来尝试对对象加锁，如果使用 CAS 替换 ThreadID 成功，就说明是第一次上锁，那么当前线程就会获得对象的偏向锁，此时会在对象头的 Mark Word 中记录当前线程 ID 和获取锁的时间 epoch 等信息，然后执行同步代码块。
全局安全点（Safe Point）：全局安全点的理解会涉及到 C 语言底层的一些知识，这里简单理解 SafePoint 是 Java 代码中的一个线程可能暂停执行的位置。

等到下一次线程在进入和退出同步代码块时就不需要进行 CAS 操作进行加锁和解锁，只需要简单判断一下对象头的 Mark Word 中是否存储着指向当前线程的线程ID，判断的标志当然是根据锁的标志位来判断的。如果用流程图来表示的话就是下面这样

关闭偏向锁

偏向锁在Java 6 和Java 7 里是默认启用的。由于偏向锁是为了在只有一个线程执行同步块时提高性能，如果你确定应用程序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁：-XX:-UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。

ReentrantLock 的基本理解
ReentrantLock 作为 Lock 显式锁的最基本实现，也是使用最频繁的一个锁实现类。它提供了两个构造函数，用于支持公平竞争锁。

public ReentrantLock()

public ReentrantLock(boolean fair)

默认无参的构造函数表示启用非公平锁，当然也可以通过第二个构造函数传入 fair 参数值为 true 指明启用公平锁。

公平锁和非公平锁的区别之处在于，公平锁在选择下一个占有锁的线程时，参考先到先得原则，等待时间越长的线程将具有更高的优先级。而非公平锁则无视这种原则。

两种策略各有利弊，公平策略可以保证每个线程都公平的竞争到锁，但是维护公平算法本身也是一种资源消耗，每一次锁请求的线程都直接被挂在队列的尾部，而只有队列头部的线程有资格使用锁，后面的都得排队。

那么假设这么一种情况，A 获得锁正在运行，B 尝试获得锁失败被阻塞，此时 C 也尝试获得锁，失败而阻塞，虽然 C 只需要很短运行时间，它依然需要等待 B 执行结束才有机会获得锁来运行。

非公平锁的前提下，A 执行结束，找到队列首部的 B 线程，开始上下文切换，假如此时的 C 过来竞争锁，非公平策略前提下，C 是可以获得锁的，并假设它迅速的执行结束了，当 B 线程被切换回来之后再去获取锁也不会有什么问题，结果是，C 线程在 B 线程的上下文切换过程中执行结束。显然，非公平策略下 CPU 的吞吐量是提高的。

但是，非公平策略的锁可能会造成某些线程饥饿，始终得不到运行，各有利弊，适时取舍。庆幸的是，我们的显式锁支持两种模式的切换选择。稍后我们将分析其中实现的细节之处。

ReentrantLock 中有以下三个内部类是比较重要的：

image

内部类 Sync 继承自我们的 AQS 并重写了部分方法，NonfairSync 和 FairSync 是 Sync 的两个子类，分别对应公平锁和非公平锁。

为什么这么做呢？

image

类 Sync 中有一个 lock 方法，而公平策略下的 lock 方法和非公平策略下的 lock 方法应该具有不同的实现，所以这里并没有写死，而是交由子类去实现它。

这其实是一种典型的设计模式，『模板方法』。

关于 AQS，我们稍后做详细的分析，这里你把它理解为一个用于记录保存当前占有锁线程信息和阻塞在该锁上所有线程信息的容器即可。

接着看 ReentrantLock，你会发现，无论是 lock 方法，lockInterruptibly 方法、tryLock 或是 unlock 方法都是透传调用 sync 的相关方法，也即 AQS 中的相关方法。

公平锁和非公平锁。

public ReentrantLock() {
    sync = new NonfairSync();
}

所谓公平锁，就是多个线程解锁的顺序与进入锁的顺序一样，即谁先锁，谁就先解锁。反之则是非公平锁。例如ReentrantLock中就有公平与非公平两种锁实现，默认是非公平锁。
非公平锁的优点在于吞吐量比公平锁大。对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。

自旋锁 VS 适应性自旋锁

在介绍自旋锁前，我们需要介绍一些前提知识来帮助大家明白自旋锁的概念。

自旋与自适应自旋：想要获取锁的线程做几个空循环 10 CAS实现

.为什么引入：

轻量级锁失败后，线程会在操作系统层面挂起

操作系统实现线程之间的切换时，需要从用户态转换到核心态，状态转换耗时

.解决方法：

当线程在获取轻量级锁时CAS操作失败时，通过自旋让线程等待，避免线程切换的开销

假设不久当前的线程可以获得锁，虚拟机会让当前想要获取锁的线程做几个空循环，可能是50个循环或100循环

结果：

如果得到锁，就顺利进入临界区；如果不能，就将线程在操作系统层面挂起，升级为重量级锁

自旋锁的优化：自适应自旋

自旋是需要消耗CPU的，如果一直获取不到锁，线程一直自旋，浪费CPU资源

线程如果自旋成功了，下次自旋的次数会更多，自旋失败了，自旋的次数就会减少。

阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长。

在许多场景中，同步资源的锁定时间很短，为了这一小段时间去切换线程，线程挂起和恢复现场的花费可能会让系统得不偿失。如果物理机器有多个处理器，能够让两个或以上的线程同时并行执行，我们就可以让后面那个请求锁的线程不放弃CPU的执行时间，看看持有锁的线程是否很快就会释放锁。

而为了让当前线程“稍等一下”，我们需让当前线程进行自旋，如果在自旋完成后前面锁定同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞而是直接获取同步资源，从而避免切换线程的开销。这就是自旋锁。

自旋锁本身是有缺点的，它不能代替阻塞。自旋等待虽然避免了线程切换的开销，但它要占用处理器时间。如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁被占用的时间很长，那么自旋的线程只会白浪费处理器资源。所以，自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，可以使用-XX:PreBlockSpin来更改）没有成功获得锁，就应当挂起线程。

自旋锁的实现原理同样也是CAS，AtomicInteger中调用unsafe进行自增操作的源码中的do-while循环就是一个自旋操作，如果修改数值失败则通过循环来执行自旋，直至修改成功。

自旋锁在JDK1.4.2中引入，使用-XX:+UseSpinning来开启。JDK 6中变为默认开启，并且引入了自适应的自旋锁（适应性自旋锁）。

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

在自旋锁中另有三种常见的锁形式:TicketLock、CLHlock和MCSlock，本文中仅做名词介绍，不做深入讲解，感兴趣的同学可以自行查阅相关资料。

synchronized用的锁是存在Java对象头里的。

JVM基于进入和退出 Monitor 对象来实现方法同步和代码块同步。代码块同步是使用 monitorenter 和 monitorexit 指令实现的，monitorenter 指令是在编译后插入到同步代码块的开始位置，而 monitorexit 是插入到方法结束处和异常处。任何对象都有一个 monitor 与之关联，当且一个 monitor 被持有后，它将处于锁定状态。

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

Monitor

Synchronized是通过对象内部的一个叫做监视器锁(monitor)来实现的，监视器锁本质又是依赖于底层的操作系统的 Mutex Lock(互斥锁)来实现的。而操作系统实现线程之间的切换需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么 Synchronized 效率低的原因。因此，这种依赖于操作系统 Mutex Lock 所实现的锁我们称之为重量级锁。

Java SE 1.6为了减少获得锁和释放锁带来的性能消耗，引入了偏向锁和轻量级锁：锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态。锁可以升级但不能降级。

所以锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁(但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级)。JDK 1.6中默认是开启偏向锁和轻量级锁的，我们也可以通过-XX:-UseBiasedLocking=false来禁用偏向锁。

下面我们就深入源码去分析分析这个 AQS 的实现情况。

Synchronized锁