ReentrantLock的实现原理分析
- 之所以叫重入锁
- 是因为同一个线程如果已经获得了锁,
- 那么后续该线程调用lock方法时不需要再次获取锁,
- 也就是不会阻塞;
- 重入锁提供了两种实现,
- 一种是非公平的重入锁,
- 另一种是公平的重入锁。
- 怎么理解公平和非公平呢?
- 如果在绝对时间上,先对锁进行获取的请求一定先被满足获得锁,
- 那么这个锁就是公平锁,
- 反之,就是不公平的。
- 简单来说公平锁就是等待时间最长的线程最优先获取锁。
- 如果在绝对时间上,先对锁进行获取的请求一定先被满足获得锁,
非公平锁的实现流程时序图
源码分析
- ReentrantLock.lock
-
public void lock() { sync.lock(); }
- 这个是获取锁的入口,调用了sync.lock;
- sync是一个实现了AQS的抽象类,
- 这个类的主要作用是用来实现同步控制的,
- 并且sync有两个实现,
- 一个是NonfairSync(非公平锁)、
- 另一个是FailSync(公平锁);
-
- 我们先来分析一下非公平锁的实现::
- NonfairSync.lock
final void lock() {
if (compareAndSetState(0, 1)) //这是跟公平锁的主要区别,一上来就试探锁是否空闲,如果可以插队,则设置获得锁的线程为当前线程
//exclusiveOwnerThread属性是AQS从父类AbstractOwnableSynchronizer中继承的属性,用来保存当前占用同步状态的线程
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1); //尝试去获取锁
}
- compareAndSetState,这个方法在前面提到过了,
- 通过cas算法去改变state的值,而这个state是什么呢?
- 在AQS中存在一个变量state,
- 对于ReentrantLock来说,
- 如果state=0表示无锁状态、如果state>0表示有锁状态。
- 所以在这里,是表示当前的state
- 如果等于0,则替换为1,
- 如果替换成功表示获取锁成功了
- 由于ReentrantLock是可重入锁,
- 所以持有锁的线程可以多次加锁,
- 经过判断加锁线程就是当前持有锁的线程时,即可加锁
- 即exclusiveOwnerThread==Thread.currentThread(),
- 每次加锁都会将state的值+1,
- state等于几,就代表当前持有锁的线程加了几次锁;
- 解锁时每解一次锁就会将state减1,
- state减到0后,锁就被释放掉,
- 这时其它线程可以加锁;
- 通过cas算法去改变state的值,而这个state是什么呢?
AbstractQueuedSynchronizer.acquire
- 如果CAS操作未能成功,说明state已经不为0,
- 此时继续acquire(1)操作,
- acquire是AQS中的方法
- 此时继续acquire(1)操作,
- 当多个线程同时进入这个方法时,
- 首先通过cas去修改state的状态,
- 如果修改成功表示竞争锁成功,
- 竞争失败的,tryAcquire会返回false
- 首先通过cas去修改state的状态,
public final void acquire(int arg) {
if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
- 这个方法的主要作用是
- Ø 尝试获取独占锁,获取成功则返回
- tryAcquire
- Ø 否则,自旋获取锁,并且判断中断标识,
- 如果中断标识为true,则设置线程中断
- selfInterrupt
- Ø addWaiter方法把当前线程封装成Node,
- 并添加到队列的尾部
- Ø 尝试获取独占锁,获取成功则返回
NonfairSync.tryAcquire
- tryAcquire方法尝试获取锁,
- 如果成功就返回,
- 如果不成功,
- 则把当前线程和等待状态信息构适成一个Node节点,
- 并将结点放入同步队列的尾部。
- 然后为同步队列中的当前节点循环等待获取锁,直到成功
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
nofairTryAcquire
- 这里可以看非公平锁的涵义,
- 即获取锁并不会严格根据争用锁的先后顺序决定。
- 这里的实现逻辑类似synchroized关键字的偏向锁的做法,
- 即可重入而不用进一步进行锁的竞争,
- 也解释了ReentrantLock中Reentrant的意义
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState(); //获取当前的状态,前面讲过,默认情况下是0表示无锁状态
if (c == 0) {
if (compareAndSetState(0, acquires)) { //通过cas来改变state状态的值,如果更新成功,表示获取锁成功,
// 这个操作外部方法lock()就做过一次,
// 这里再做只是为了再尝试一次,尽量以最简单的方式获取锁。
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {//如果当前线程等于获取锁的线程,表示重入,直接累加重入次数
int nextc = c + acquires;
if (nextc < 0) // overflow 如果这个状态值越界,抛出异常;如果没有越界,则设置后返回true
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
//如果状态不为0,且当前线程不是owner,则返回false。
return false; //获取锁失败,返回false
}
addWaiter
- 当前锁如果已经被其他线程锁持有,
- 那么当前线程来去请求锁的时候,会进入这个方法,
- 这个方法主要是把当前线程封装成node,
- 添加到AQS的链表中
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode); //创建一个独占的Node节点,mode为排他模式
// 尝试快速入队,如果失败则降级至full enq
Node pred = tail; // tail是AQS的中表示同步队列队尾的属性,刚开始为null,所以进行enq(node)方法
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) { // 防止有其他线程修改tail,使用CAS进行修改,如果失败则降级至full enq
pred.next = node; // 如果成功之后旧的tail的next指针再指向新的tail,成为双向链表
return node;
}
}
enq(node); // 如果队列为null或者CAS设置新的tail失败
return node;
}
enq
- enq就是通过自旋操作
- 把当前节点加入到队列中
private Node enq(final Node node) {
for (;;) { //无效的循环,为什么采用for(;;),是因为它执行的指令少,不占用寄存器
Node t = tail;// 此时head, tail都为null
if (t == null) { // Must initialize// 如果tail为null则说明队列首次使用,需要进行初始化
if (compareAndSetHead(new Node()))// 设置头节点,如果失败则存在竞争,留至下一轮循环
tail = head; // 用CAS的方式创建一个空的Node作为头结点,因为此时队列中只一个头结点,所以tail也指向head,第一次循环执行结束
} else {
//进行第二次循环时,tail不为null,进入else区域。
// 将当前线程的Node结点的prev指向tail,然后使用CAS将tail指向Node
//这部分代码和addWaiter代码一样,将当前节点添加到队列
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node; //t此时指向tail,所以可以CAS成功,将tail重新指向CNode。
// 此时t为更新前的tail的值,即指向空的头结点,t.next=node,
// 就将头结点的后续结点指向Node,返回头结点
return t;
}
}
}
}
代码运行到这里,aqs队列的结构就是这样一个表现::
acquireQueued
- addWaiter返回了插入的节点,
- 作为acquireQueued方法的入参,
- 这个方法主要用于争抢锁
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (; ; ) {
final Node p = node.predecessor();// 获取prev节点,若为null即刻抛出 NullPointException
if (p == head && tryAcquire(arg)) {// 如果前驱为head才有资格进行锁的抢夺
setHead(node); // 获取锁成功后就不需要再进行同步操作了,获取锁成功的线程作为新的head节点
//凡是head节点,head.thread与head.prev永远为null, 但是head.next不为null
p.next = null; // help GC
failed = false; //获取锁成功
return interrupted;
}
//如果获取锁失败,则根据节点的waitStatus决定是否需要挂起线程
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())// 若前面为true,则执行挂起,待下次唤醒的时候检测中断的标志
interrupted = true;
}
} finally {
if (failed) // 如果抛出异常则取消锁的获取,进行出队(sync queue)操作
cancelAcquire(node);
}
}
原来的head节点释放锁以后,会从队列中移除,
- 原来head节点的next节点会成为head节点
shouldParkAfterFailedAcquire
- 从上面的分析可以看出,只有队列的第二个节点可以有机会争用锁,
- 如果成功获取锁,则此节点晋升为头节点。
- 对于第三个及以后的节点,if (p == head)条件不成立,
- 首先进行shouldParkAfterFailedAcquire(p, node)操作
- 方法是判断一个争用锁的线程是否应该被阻塞。
- 它首先判断一个节点的前置节点的状态是否为Node.SIGNAL,
- 如果是,是说明此节点已经将状态设置
- 设置的作用是:如果锁释放,则应当通知它,
- 所以它可以安全的阻塞了,返回true
- 如果是,是说明此节点已经将状态设置
- 它首先判断一个节点的前置节点的状态是否为Node.SIGNAL,
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus; //前继节点的状态
if (ws == Node.SIGNAL)//如果是SIGNAL状态,意味着当前线程需要被unpark唤醒
return true;
// 如果前节点的状态大于0,即为CANCELLED状态时,
//则会从前节点开始逐步循环找到一个没有被“CANCELLED”节点设置为当前节点的前节点,返回false。
// 在下次循环执行shouldParkAfterFailedAcquire时,返回true。
// 这个操作实际是把队列中CANCELLED的节点剔除掉。
if (ws > 0) {// 如果前继节点是“取消”状态,则设置 “当前节点”的 “当前前继节点” 为 “‘原前继节点 '的前继节点”。
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else { // 如果前继节点为“0”或者“共享锁”状态,则设置前继节点为SIGNAL状态。
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
解读:假如有t1,t2两个线程都加入到了链表中
- 如果head节点位置的线程一直持有锁,
- 那么t1和t2就是挂起状态,
- 而HEAD以及Thread1的的awaitStatus都是SIGNAL,
- 在多次尝试获取锁失败以后,就会通过下面的方法进行挂起
- 这个地方就是避免了惊群效应,每个节点只需要关心上一个节点的状态即可
SIGNAL:值为-1,
- 表示当前节点的的后继节点将要或者已经被阻塞,
- 在当前节点释放的时候需要unpark后继节点;
CONDITION:值为-2,
- 表示当前节点在等待condition,即在condition队列中;
PROPAGATE:值为-3,
- 表示releaseShared需要被传播给后续节点
- (仅在共享模式下使用);
parkAndCheckInterrupt
- 如果shouldParkAfterFailedAcquire返回了true,
- 则会执行:“parkAndCheckInterrupt()”方法,
- 它是通过LockSupport.park(this)将当前线程挂起到WATING状态,
- 它需要等待一个中断、unpark方法来唤醒它,
- 通过这样一种FIFO的机制的等待,来实现了Lock的操作
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);// LockSupport提供park()和unpark()方法实现阻塞线程和解除线程阻塞
return Thread.interrupted();
}
ReentrantLock.unlock
- 加锁的过程分析完以后,再来分析一下释放锁的过程,调用release方法,这个方法里面做两件事,
- 1,释放锁 ;
- 2,唤醒park的线程
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
tryRelease
- 这个动作可以认为就是一个设置锁状态的操作,
- 而且是将状态减掉传入的参数值(参数是1),
- 如果结果状态为0,就将排它锁的Owner设置为null,
- 以使得其它的线程有机会进行执行。
- 而且是将状态减掉传入的参数值(参数是1),
- 在排它锁中,加锁的时候状态会增加1(当然可以自己修改这个值),
- 在解锁的时候减掉1,同一个锁,在可以重入后,可能会被叠加为2、3、4这些值,
- 只有unlock()的次数与lock()的次数对应才会将Owner线程设置为空,
- 而且也只有这种情况下才会返回true。
protected final boolean tryRelease(int releases) {
int c = getState() - releases; // 这里是将锁的数量减1
if (Thread.currentThread() != getExclusiveOwnerThread())// 如果释放的线程和获取锁的线程不是同一个,
// 抛出非法监视器状态异常
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
// 由于重入的关系,不是每次释放锁c都等于0,
// 直到最后一次释放锁时,才会把当前线程释放
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
unparkSuccessor
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
*/
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);
}
LockSupport.unpark(s.thread);
- LockSupport类是Java6引入的一个类,提供了基本的线程同步原语。
- LockSupport实际上是调用了Unsafe类里的函数,归结到Unsafe里,
- 只有两个函数:
-
public native void unpark(Thread jthread); public native void park(boolean isAbsolute, long time);
-
- unpark函数为线程提供“许可(permit)”,
- 线程调用park函数则等待“许可”。
- 这个有点像信号量,但是这个“许可”是不能叠加的,“许可”是一次性的。
- permit相当于0/1的开关,默认是0,
- 调用一次unpark就加1变成了1.
- 调用一次park会消费permit,又会变成0。
- 如果再调用一次park会阻塞,因为permit已经是0了。
- 直到permit变成1.
- 这时调用unpark会把permit设置为1.
- 每个线程都有一个相关的permit,permit最多只有一个,
- 重复调用unpark不会累积
- 在使用LockSupport之前,
- 我们对线程做同步,只能使用wait和notify,
- 但是wait和notify其实不是很灵活,并且耦合性很高,
- 调用notify必须要确保某个线程处于wait状态,
- 而park/unpark模型真正解耦了线程之间的同步,先后顺序没有直接关联,
- 同时线程之间不再需要一个Object或者其它变量来存储状态,
- 不再需要关心对方的状态。
总结
- 分析了独占式同步状态获取和释放过程后,
- 做个简单的总结:
- 在获取同步状态时,同步器维护一个同步队列,
- 获取状态失败的线程都会被加入到队列中并在队列中进行自旋;
- 移出队列(或停止自旋)的条件是
- 前驱节点为头节点且成功获取了同步状态。
- 在释放同步状态时,同步器调用tryRelease(int arg)方法释放同步状态,
- 然后唤醒头节点的后继节点。
- 在获取同步状态时,同步器维护一个同步队列,