一文吃透AQS&ReentrantLock的前世与今生
一.前言
hello，everyone，好久不见。最近工作太忙，一直没时间写博客。刚空下来，想了想java里面还有一个比较重要的体系：锁，还没有分享过。本文开始将从JUC包的基础数据结构AbstractQueuedSynchronizer（下文简称为AQS）为切入点开始分析JDK包中的锁机制。AQS是JUC包中许多同步类（Lock、Semaphore、ReentrantLock等）的基石，学好AQS对理解JUC包有重要的作用。本文介绍AQS时将结合ReentrantLock为大家做介绍，希望能够帮助到大家。
二.AQS
AQS是一种提供了原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架。本文会从应用层逐渐深入到原理层，并通过ReentrantLock的基本特性和ReentrantLock与AQS的关联，来深入解读AQS相关独占锁的知识点。
本篇文章核心为AQS原理剖析，ReentrantLock仅做简单介绍，后续将会出一个专栏介绍，关注订阅我的java专栏不迷路~
2.1.AQS概览
2.1.1.AQS类框架图
图片来源：https://tech.meituan.com/2019/12/05/aqs-theory-and-apply.html
2.1.2.核心变量
//双向队列头结点，此节点的线程为占有当前state变量的线程
private transient volatile Node head;
//尾部结点，发生锁竞争时，未抢到锁的线程将会排队到尾部
private transient volatile Node tail;
/**
* 状态变量，AQS通过维护state变量的值来控制临界资源的访问
* 初始化为0表示没有线程占用，如果使用独占锁访问，抢到锁的线程会将state的值加1，可重入锁的实现就是基于此
* 字段，如果线程id等于持有state变量的线程id，则将state加1，后续释放锁时，也是在此处重复减1。后续在
* ReentrantLock中将会演示。
*/
private volatile int state;说明：
AQS通过维护volatile修饰的state变量的值来控制对临界资源的访问，state的访问提供一下几个方法
getState()
setState()
compareAndSetState()【CAS】：设置并比较
//CAS比较并且设置值，又是熟悉的unsafe方法，底层调用C语言方法,利用JMM，在多线程环境下，保证修改的
//值是主存中最新的值
protected final boolean compareAndSetState(int expect, int update) {
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
关于CAS的解析可以参考：https://www.jianshu.com/p/ae25eb3cfb5d
在java中常被用来乐观锁的实现
在博主另一篇文章ConcurrentHashMap中也有过介绍：https://juejin.cn/post/6960898411314823204AQS定义两种资源共享方式：
1.Exclusive（独占，只有一个线程能执行，如ReentrantLock）
2.Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。
不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：
- isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
- tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
- tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
- tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
- tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。
以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。
再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。
一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。
2.1.3.AQS双向队列
//node节点为AQS内部双向队列的基础数据结构
static final class Node {
//指示节点正在共享模式下等待的标记
static final Node SHARED = new Node();
//指示节点正在以独占模式等待的标记
static final Node EXCLUSIVE = null;
//表示当前结点已取消调度。当timeout或被中断（响应中断的情况下），会触发变更为此状态，进入该状态后的结点将不会再变化。
static final int CANCELLED = 1;
//表示后继结点在等待当前结点唤醒。后继结点入队时，会将前继结点的状态更新为SIGNAL
static final int SIGNAL = -1;
//表示结点等待在Condition上，当其他线程调用了Condition的signal()方法后，CONDITION状态的结点将从等待队列转移到同步队列中，等待获取同步锁
static final int CONDITION = -2;
//共享模式下，前继结点不仅会唤醒其后继结点，同时也可能会唤醒后继的后继结点
static final int PROPAGATE = -3;
//当前节点的等待状态，即为上述的状态值
volatile int waitStatus;
//当前节点的前置节点
volatile Node prev;
//当前节点的后置节点
volatile Node next;
//当前节点的线程
volatile Thread thread;
//下一个等待节点
Node nextWaiter;
//当前是否为共享模式
final boolean isShared() {
return nextWaiter == SHARED;
}
//返回前置节点
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
Node() {
}
Node(Thread thread, Node mode) {
this.nextWaiter = mode;
this.thread = thread;
}
Node(Thread thread, int waitStatus) {
this.waitStatus = waitStatus;
this.thread = thread;
}
}AQS内部通过维护一个双向链表来控制临界资源的访问。头结点为当前拥有访问共享变量权限的线程，后续节点为等待唤醒访问的节点。
2.2.核心方法解析
说了这么多，其实AQS就是一个完整的API库，在JUC包中提供的很多工具类都是基于AQS的资源访问与释放等方法来实现的。
2.2.1.acquire(int)
acquire（int）方法是独占模式下线程获取共享资源的顶层入口，资源获取（加锁）入口。如果获取资源成功，则表示线程拿到state变量的访问权限，则对应线程可以执行当前的业务逻辑；获取失败则将节点入队。下面来看一下代码
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}//空方法，此方法让用户可以自定义去控制state变量的访问
protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}private Node addWaiter(Node mode) {
//以给定模式构造结点。mode有两种：EXCLUSIVE（独占）和SHARED（共享）
Node node = new Node(Thread.currentThread(), mode);
//尝试快速方式直接放到队尾。
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
//上一步失败则通过enq入队。
enq(node);
return node;
}private Node enq(final Node node) {
//CAS"自旋"，直到成功加入队尾
for (;;) {
Node t = tail;
// 队列为空，创建一个空的标志结点作为head结点，并将tail也指向它。
if (t == null) {
if (compareAndSetHead(new Node()))
tail = head;
/正常流程，放入队尾
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}final boolean acquireQueued(final Node node, int arg) {
//标记是否成功拿到资源
boolean failed = true;
try {
//标记等待过程中是否被中断过
boolean interrupted = false;
//自旋
for (;;) {
//获取前驱节点
final Node p = node.predecessor();
/如果前驱是head，即该结点已成老二，那么便有资格去尝试获取资源（可能是老大释放完资源唤醒自己的，当然也可能被interrupt了）。
if (p == head && tryAcquire(arg)) {
//拿到资源后，将head指向该结点。所以head所指的标杆结点，就是当前获取到资源的那个结点或null。
setHead(node);
// setHead中node.prev已置为null，此处再将head.next置为null，就是为了方便GC回收以前的head结点。也就意味着之前拿完资源的结点出队了！
p.next = null;
// 成功获取资源
failed = false;
/返回等待过程中是否被中断过
return interrupted;
}
//如果自己可以休息了，就通过park()进入waiting状态，直到被unpark()。如果不可中断的情况下被中断了，那么会从park()中醒过来，发现拿不到资源，从而继续进入park()等待。
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
//如果等待过程中被中断过，哪怕只有那么一次，就将interrupted标记为true
interrupted = true;
}
} finally {
// 如果等待过程中没有成功获取资源（如timeout，或者可中断的情况下被中断了），那么取消结点在队列中的等待。
if (failed)
cancelAcquire(node);
}
}private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
//拿到前驱的状态
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
//如果已经告诉前驱拿完号后通知自己一下，那就可以安心休息了
return true;
if (ws > 0) {
// 如果前驱放弃了，那就一直往前找，直到找到最近一个正常等待的状态，并排在它的后边。
//注意：那些放弃的结点，由于被自己“加塞”到它们前边，它们相当于形成一个无引用链，稍后就会被GC回收
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
//如果前驱正常，那就把前驱的状态设置成SIGNAL，告诉它拿完号后通知自己一下。有可能失败，人家说不定刚刚释放完呢！
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}private final boolean parkAndCheckInterrupt() {
//调用park()使线程进入waiting状态
LockSupport.park(this);
//如果被唤醒，查看自己是不是被中断的。Thread.interrupted()会清除当前线程的中断标记位
return Thread.interrupted();
}看完源码总结一下
- 调用自定义同步器的tryAcquire()尝试直接去获取资源，如果成功则直接返回；
- 没成功，则addWaiter()将该线程加入等待队列的尾部，并标记为独占模式；
- acquireQueued()使线程在等待队列中休息，有机会时（轮到自己，会被unpark()）会去尝试获取资源。获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
- 如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断selfInterrupt()，将中断补上。
2.2.2. release(int)
与acquire（int）方法对应，release(int)是独占模式下线程释放共享资源的顶层入口，资源释放（解锁）入口。如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。下面来看一下源码
public final boolean release(int arg) {
if (tryRelease(arg)) {
//找到头结点
Node h = head;
if (h != null && h.waitStatus != 0)
//唤醒等待队列里的下一个线程
unparkSuccessor(h);
return true;
}
return false;
}//同理为空方法，由对应的实现类来实现
protected boolean tryRelease(int arg) {
throw new UnsupportedOperationException();
}private void unparkSuccessor(Node node) {
//这里，node一般为当前线程所在的结点。
int ws = node.waitStatus;
//置零当前线程所在的结点状态，允许失败。
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
//找到下一个需要唤醒的结点s
Node s = node.next;
/如果为空或已取消
if (s == null || s.waitStatus > 0) {
s = null;
// 从后向前找。
for (Node t = tail; t != null && t != node; t = t.prev)
//从这里可以看出，<=0的结点，都是还有效的结点。
if (t.waitStatus <= 0)
s = t;
}
//唤醒
if (s != null)
LockSupport.unpark(s.thread);
}release的逻辑相对来说比较简单，将头结点置空等待GC，往后寻找未被取消的节点，waitStatus<=0的节点，将其唤醒作为头结点，获取state的访问权限。
2.2.3.acquireShared(int)
此方法是共享模式下线程获取共享资源的顶层入口。它会获取指定量的资源，获取成功则直接返回，获取失败则进入等待队列，直到获取到资源为止，整个过程忽略中断。下面来看一下源码
public final void acquireShared(int arg) {
//AQS已经把其返回值的语义定义好了：负值代表获取失败；0代表获取成功，但没有剩余资源；正数表示获取成功，
//还有剩余资源，其他线程还可以去获取。尝试获取资源，成功则直接返回
tryAcquireShared()
if (tryAcquireShared(arg) < 0)
失败则通过doAcquireShared()进入等待队列，直到获取到资源为止才返回
doAcquireShared(arg);
}//同理业务侧自己实现
protected int tryAcquireShared(int arg) {
throw new UnsupportedOperationException();
}private void doAcquireShared(int arg) {
//加入队列尾部
final Node node = addWaiter(Node.SHARED);
//是否成功标志
boolean failed = true;
try {
//等待过程中是否被中断过的标志
boolean interrupted = false;
for (;;) {
//前驱
final Node p = node.predecessor();
//如果到head的下一个，因为head是拿到资源的线程，此时node被唤醒，很可能是head用完资源来唤醒自己的
if (p == head) {
//尝试获取资源
int r = tryAcquireShared(arg);
//成功
if (r >= 0) {
setHeadAndPropagate(node, r);
p.next = null; // help GC
/如果等待过程中被打断过，此时将中断补上。
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
//判断状态，寻找安全点，进入waiting状态，等着被unpark()或interrupt()
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
//head指向自己
setHead(node);
//如果还有剩余量，继续唤醒下一个邻居线程
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}整体逻辑与入队独占锁一致
跟独占模式比，还有一点需要注意的是，这里只有线程是head.next时（“老二”），才会去尝试获取资源，有剩余的话还会唤醒之后的队友。那么问题就来了，假如老大用完后释放了5个资源，而老二需要6个，老三需要1个，老四需要2个。老大先唤醒老二，老二一看资源不够，他是把资源让给老三呢，还是不让？答案是否定的！老二会继续park()等待其他线程释放资源，也更不会去唤醒老三和老四了。独占模式，同一时刻只有一个线程去执行，这样做未尝不可；但共享模式下，多个线程是可以同时执行的，现在因为老二的资源需求量大，而把后面量小的老三和老四也都卡住了。当然，这并不是问题，只是AQS保证严格按照入队顺序唤醒罢了（保证公平，但降低了并发）
2.2.4. releaseShared()
反向释放 共享锁
public final boolean releaseShared(int arg) {
//尝试释放资源
if (tryReleaseShared(arg)) {
//唤醒后继结点
doReleaseShared();
return true;
}
return false;
}private void doReleaseShared() {
for (;;) {
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue;
//唤醒后继
unparkSuccessor(h);
}
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue;
}
// head发生变化
if (h == head)
break;
}
}此方法的流程也比较简单，一句话：释放掉资源后，唤醒后继。跟独占模式下的release()相似，但有一点稍微需要注意：独占模式下的tryRelease()在完全释放掉资源（state=0）后，才会返回true去唤醒其他线程，这主要是基于独占下可重入的考量；而共享模式下的releaseShared()则没有这种要求，共享模式实质就是控制一定量的线程并发执行，那么拥有资源的线程在释放掉部分资源时就可以唤醒后继等待结点。例如，资源总量是13，A（5）和B（7）分别获取到资源并发运行，C（4）来时只剩1个资源就需要等待。A在运行过程中释放掉2个资源量，然后tryReleaseShared(2)返回true唤醒C，C一看只有3个仍不够继续等待；随后B又释放2个，tryReleaseShared(2)返回true唤醒C，C一看有5个够自己用了，然后C就可以跟A和B一起运行。而ReentrantReadWriteLock读锁的tryReleaseShared()只有在完全释放掉资源（state=0）才返回true，所以自定义同步器可以根据需要决定tryReleaseShared()的返回值。
三.ReentrantLock简介及使用
3.1.介绍
ReentrantLock意思为可重入锁，指的是一个线程能够对一个临界资源重复加锁。常被用来与Synchronized关键字做对比。本节将针对前文对AQS的原理的讲解进行串联，帮助大家理解AQS在ReentrantLock中起到的作用。
Synchronized与ReentrantLock区别：https://juejin.cn/post/6844903695298068487
3.1.1.公平锁与非公平锁
ReentrantLock支持两种加锁方式，公平锁与非公平锁。
以排对吃肯德基的场景介绍一下ReentrantLock中公平锁与非公平锁
公平锁：我想吃肯德基，看到前面有人在排队，老老实实的排到现有队伍的最后面，等前面的人买完我再买。
非公平锁：：我想吃肯德基，看到前面有人在排队，我不想排，直接插队去买，如果这个时候你下单成功了，那你就可以省去排队时间吃到了肯德基，但是如果下单失败，就老老实实的继续去排队。
优点 | 缺点 | |
|---|---|---|
公平锁 | 所有的线程都能得到资源，不会饿死在队列中 | 吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大 |
非公平锁 | 可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量 | 可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死 |
3.2.ReentrantLock使用
3.2.1.ReentrantLock构造方法
ReentrantLock默认使用非公平锁
//默认构造方法中非公平锁
public ReentrantLock() {
sync = new NonfairSync();
}
//非公平锁与公平锁自行选择
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}/**
* 非公平锁
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
/**
* 公平锁
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
//尝试加载资源
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}3.2.2.ReentrantLock加锁与解锁使用
到现在为止大家应该还不清楚ReentrantLock与AQS到底是怎么做关联的
我们先来简单使用一下ReentrantLock
不加锁
public class Demo {
int count = 1;
public void add(){
this.count ++;
}
public static void main(String[] args) throws Exception{
Demo demo = new Demo();
ExecutorService executorService = Executors.newFixedThreadPool(30);
List<Runnable> runnables = new ArrayList<>();
List<Future<?>> futures = new ArrayList<Future<?>>();
for (int i = 0; i < 1000; i++) {
runnables.add(()->{
demo.add();
});
}
runnables.forEach(e->{
futures.add(executorService.submit(e));
});
//等待所有任务执行完成
for(Future<?> f : futures) {
try {
f.get();
} catch (Exception e) {
e.printStackTrace();
}
}
System.out.println(demo.count);
}
}
控制台输出：
987
基本上不等于1001加锁
public class Demo {
ReentrantLock reentrantLock = new ReentrantLock();
int count = 1;
public void add(){
reentrantLock.lock();
try{
this.count ++;
}catch (Exception e){
e.printStackTrace();
}finally {
reentrantLock.unlock();
}
}
public static void main(String[] args) throws Exception{
Demo demo = new Demo();
ExecutorService executorService = Executors.newFixedThreadPool(30);
List<Runnable> runnables = new ArrayList<>();
List<Future<?>> futures = new ArrayList<Future<?>>();
for (int i = 0; i < 1000; i++) {
runnables.add(()->{
demo.add();
});
}
runnables.forEach(e->{
futures.add(executorService.submit(e));
});
//等待所有任务执行完成
for(Future<?> f : futures) {
try {
f.get();
} catch (Exception e) {
e.printStackTrace();
}
}
System.out.println(demo.count);
}
}3.2.3.ReentrantLock加锁与解锁解析
从3.2.2.的代码里面可以看到ReentrantLock的加锁与解锁依靠lock()与unlock()方法。我们去看看这两个方法在干什么
1.Lock()方法
public void lock() {
sync.lock();
}abstract static class Sync extends AbstractQueuedSynchronizer {
//省略不必要代码
abstract void lock();
//省略不必要代码
}查看lock方法实现
有公平锁与非公平锁的实现。
为展示方便，以公平锁实现逻辑为例
//FairSync类
final void lock() {
acquire(1);
}//资源获取方法
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}在FairSync类中还有一个方法tryAcquire
protected final boolean tryAcquire(int acquires) {
//获取当前线程变量
final Thread current = Thread.currentThread();
//获取共享变量
int c = getState();
//未被占用
if (c == 0) {
//公平锁体现，如果没有等待队列，并且CAS设置状态成功，则拿到锁
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
//如果被占用了，但是占用的线程是当前线程，则将state加1，可重入锁的体现
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}发现他是一个覆盖方法，与上文讲的业务侧实现的机制一致。
protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}到此我们将ReentrantLock方法与AQS的方法关联起来了，下面我们来梳理一下公平锁的加锁的步骤
2.unlock()方法
//ReentrantLock方法
public void unlock() {
sync.release(1);
}//AQS内部方法
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}3.2.4.公平锁与非公平锁实现差异
我们知道ReentrantLock是独占锁，那么里面的公平锁与非公平锁的差异点在哪里呢？
不看源码，我们结合上文对AQS与公平锁实现的代码的解析大家觉得能在哪里体现呢？
肯定是lock（）方法，公平锁中lock方法发现如果共享变量被非当前线程的线程给占用了，并且已经有线程在排队了，那么就老老实实的去排队了。我们回到肯德基那张图，非公平锁知道state被占用的情况下，并且有线程在排队时，会直接尝试插队。ok，带着这个思路我们看一下非公平锁的实现
final void lock() {
//第一次插队，不管当前state是否被占用，先cas一次碰运气看看能不能抢到资源访问的权限
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
//未被占用，则设置值
if (c == 0) {
//再抢一次
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
//重入锁实现
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}- 非公平锁在调用 lock 后，首先就会调用 CAS 进行一次抢锁，如果这个时候恰巧锁没有被占用，那么直接就获取到锁返回了。
- 非公平锁在 CAS 失败后，和公平锁一样都会进入到
tryAcquire方法，在tryAcquire方法中，如果发现锁这个时候被释放了（state == 0），非公平锁会直接 CAS 抢锁，但是公平锁会判断等待队列是否有线程处于等待状态，如果有则不去抢锁，乖乖排到后面。
四.参考引用及鸣谢
图文思路参考：https://tech.meituan.com/2019/12/05/aqs-theory-and-apply.html
相关文章
- k8s创建pv&pvc
- Maven 换源 & Mybatis 开启 Log4j 日志框架
- 更强大的 MQTT over QUIC 桥接 & Azure 桥接
- R&D奇谭 第6期：找程序员女婿
- H3C路由交换 Smart Link & Monitor Link
- 非约束委派&&约束委派
- Luminar 4 for mac&win(全功能图像处理软件)
- [52ABP]Docker&Ubuntu从入门到实战开课啦~
- Python迭代器&生成器：分享贴近实际运维开发场景的小案例
- AMP MySQL升级提升数据库性能的必要之举（amp mysql升级）
- AMP与Oracle结合提升数据库性能（$amp oracle）
- <meta>正则
- JavascripthasOwnProperty方法&in关键字