java并发包下很多API都是基于AQS来实现的加锁和释放锁等功能的,比如ReentrantLock、ReentrantReadWriteLock底层都是基于AQS来实现的。AQS是java并发包的基础类,今天这一节主要是梳理AQS的重要概念和原理细节。
ReentrantLock核心组件
ReentrantLock核心有3个组件:state、owner、AQS(抽象队列同步器,简单的说就是一个等待队列Queue)。如下图所示:
ReentrantLock内部包含了一个三个静态内部类,Sync,FairSync和NonfairSync,其中FairSync和NonfairSync都是继承自AQS。
AQS中的维护了一个state变量,通过volatile修饰的int类型的,代表了加锁的状态。初始状态下,这个state的值是0。
private volatile int state;
AQS中维护了head、tail以及Node内部类等,这里构成了一个FIFO(先进先出)的线程等待队列。
private transient volatile Node head;
private transient volatile Node tail;
static final class Node {
//节点状态
static final Node SHARED = new Node();
static final Node EXCLUSIVE = null;
static final int CANCELLED = 1;
static final int SIGNAL = -1;
static final int CONDITION = -2;
static final int PROPAGATE = -3;
volatile Node prev;
volatile Node next;
//节点持有的线程
volatile Thread thread;
//....省略其他...
}
同时AQS又继承了AbstractOwnableSynchronizer类,因此又维护了一个owner变量,用来记录当前加锁的是哪个线程,初始化状态下,这个变量是null。
private transient Thread exclusiveOwnerThread
AQS加锁和释放原理
1、加锁流程
假设有两个线程同时过来申请锁资源,线程1先获得锁,线程2需要等待的话,主要的流程如下:
- 两个线程同时调用 lock 方法,线程1通过
CAS(0,1)
操作将state值从0变为1,成功加锁。 - 线程1通过
CAS(0,1)
成功后,设置当前加锁线程为自己 - 线程2此时也进行
CAS(0,1)
,此时state已经为1调用肯定会失败 - 于是再查看加锁线程是否为自己,如果不是则放入等待队列
- 线程2此时调用
LockSupport.park()
挂起当前线程。
2.释放流程
- 线程1执行任务成功调用 unlock 方法,state变量的值递减1,如果state值为0,加锁线程设置为null,彻底释放锁。
- 此时进入等待队列的队头,调用
LockSupport.unpark()
唤醒线程2重新尝试加锁 - 线程2CAS操作将state从0变为1成功之后代表加锁成功,将state设置为1。
- 把“加锁线程”设置为线程2自己,同时线程2自己就从等待队列中出队了。
公平与非公平,可重入与独占
1.ReentrantLock是如何实现非公平和公平的?
ReentrantLock通过两个Sync的子类——FairSync和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);
}
}
再看公平锁的源码,和上面相比仅仅是一个if
逻辑的区别。非公平的锁NonfairSync会多了一个判断,先尝试来加个锁。
static final class FairSync extends Sync {
final void lock() {
acquire(1);
}
}
非公平的这个if
操作可以理解为如果线程1释放了,别人过来加锁,直接先尝试插个队的意思,有可能AQS队列中的线程2还没被唤醒了,被别人抢走了锁,让别的线程加锁成功了。可以概况为一句话讲,由于非公平锁,加锁前多了一个尝试获取锁的操作,导致了可能会有线程插队。
另外在公平锁的尝试加锁过程中,还多了一个 hasQueuedPredecessors()
的判断,这里限制了如果有人排队,其他线程就不能插队加锁。所以就算线程1释放锁,线程3过来加锁,由于lock方法没有了非公平锁的if(上来尝试CAS修改state,加锁的代码),线程3就只能入队。
这里可以看到公平锁比非公平锁的代码多了一个判断,判断队列中是否有等待线程。有的话也只能乖乖排队。
总结来看,公平锁主要体现在两点上:
- 第一处是在lock方法加锁时,没有尝试CAS加锁修改state的if判断,保证释放锁的时候不会有线程插队加锁。(非公平锁中,入队过程可能还会尝试加锁,也有可能造成插队加锁,大家可以自己屡一下代码看看)
- 第二处是如果已经有人加锁,在入队过程中,也通过一个hasQueuedPredecessors判断保证了按顺序入队,在入队的过程中不会再次尝试加锁。
2.可重入锁和不可重入锁
ReentrantLock通过AQS的state变量巧妙的实现了可重入加锁。如果是同一个线程调用了lock方法,加锁,state会在现有值上加+1,每再次加一次锁,就是一次可重入,所以就加锁可重入锁。也就是说:同一个线程可以使用同一个ReentrantLock进行反复加锁。(sychronized的重量级Monitor锁也是可重入锁。)
另外,释放锁的话,肯定需要释放所多次,同一个线程加锁了几次,就需要释放几次,需要将state值恢复为0才算真正的释放锁,别的线程才能获取到。
3. 独占锁 VS 共享锁
所谓独占锁,就是只要有一个线程加锁,其他人都得靠边站,这把锁属于某个线程独占,这就是独占锁。默认reentrantLock.lock创建的是非公平的可重入独占锁!
共享锁是什么意思呢?意思就是可以和别的线程同时持有一把锁,比如之后要讲的读写锁。线程1加了读锁,线程2还是可以加读锁的,它们共享一把锁。这样的锁就是一把共享锁。
参考引用:
1、初识ReenranctLock加锁的AQS底层原理
2、你知道ReentrantLock 公平、非公平、可重入、独占、共享锁都是什么意思吗?
3、我画了35张图,就是为了让你深入理解 AQS
4、大白话聊聊Java并发面试问题之谈谈你对AQS的理解?【石杉的架构笔记】