ReentrantLock源码详解--条件锁

问题

(1)条件锁是什么?

(2)条件锁适用于什么场景?

(3)条件锁的await()是在其它线程signal()的时候唤醒的吗?

简介

条件锁,是指在获取锁之后发现当前业务场景自己无法处理,而需要等待某个条件的出现才可以继续处理时使用的一种锁。

比如,在阻塞队列中,当队列中没有元素的时候是无法弹出一个元素的,这时候就需要阻塞在条件notEmpty上,等待其它线程往里面放入一个元素后,唤醒这个条件notEmpty,当前线程才可以继续去做“弹出一个元素”的行为。

注意,这里的条件,必须是在获取锁之后去等待,对应到ReentrantLock的条件锁,就是获取锁之后才能调用condition.await()方法。

在java中,条件锁的实现都在AQS的ConditionObject类中,ConditionObject实现了Condition接口,下面我们通过一个例子来进入到条件锁的学习中。

使用示例

public class ReentrantLockTest {
public static void main(String[] args) throws InterruptedException {
// 声明一个重入锁
ReentrantLock lock = new ReentrantLock();
// 声明一个条件锁
Condition condition = lock.newCondition();
new Thread(()->{
try {
lock.lock(); // 1
try {
System.out.println("before await"); // 2
// 等待条件
condition.await(); // 3
System.out.println("after await"); // 10
} finally {
lock.unlock(); // 11
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
// 这里睡1000ms是为了让上面的线程先获取到锁
Thread.sleep(1000);
lock.lock(); // 4
try {
// 这里睡2000ms代表这个线程执行业务需要的时间
Thread.sleep(2000); // 5
System.out.println("before signal"); // 6
// 通知条件已成立
condition.signal(); // 7
System.out.println("after signal"); // 8
} finally {
lock.unlock(); // 9
}
}
}

上面的代码很简单,一个线程等待条件,另一个线程通知条件已成立,后面的数字代表代码实际运行的顺序,如果你能把这个顺序看懂基本条件锁掌握得差不多了。

源码分析

ConditionObject的主要属性

public class ConditionObject implements Condition, java.io.Serializable {
/** First node of condition queue. */
private transient Node firstWaiter;
/** Last node of condition queue. */
private transient Node lastWaiter;
}

可以看到条件锁中也维护了一个队列,为了和AQS的队列区分,我这里称为条件队列,firstWaiter是队列的头节点,lastWaiter是队列的尾节点,它们是干什么的呢?接着看。

lock.newCondition()方法

新建一个条件锁。

// ReentrantLock.newCondition()
public Condition newCondition() {
return sync.newCondition();
}
// ReentrantLock.Sync.newCondition()
final ConditionObject newCondition() {
return new ConditionObject();
}
// AbstractQueuedSynchronizer.ConditionObject.ConditionObject()
public ConditionObject() { }

新建一个条件锁最后就是调用的AQS中的ConditionObject类来实例化条件锁。

condition.await()方法

condition.await()方法,表明现在要等待条件的出现。

// AbstractQueuedSynchronizer.ConditionObject.await()
public final void await() throws InterruptedException {
// 如果线程中断了,抛出异常
if (Thread.interrupted())
throw new InterruptedException();
// 添加节点到Condition的队列中,并返回该节点
Node node = addConditionWaiter();
// 完全释放当前线程获取的锁
// 因为锁是可重入的,所以这里要把获取的锁全部释放
int savedState = fullyRelease(node);
int interruptMode = 0;
// 是否在同步队列中
while (!isOnSyncQueue(node)) {
// 阻塞当前线程
LockSupport.park(this);

// 上面部分是调用await()时释放自己占有的锁,并阻塞自己等待条件的出现
// *************************分界线************************* //
// 下面部分是条件已经出现,尝试去获取锁

if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}

// 尝试获取锁,注意第二个参数,这是上一章分析过的方法
// 如果没获取到会再次阻塞(这个方法这里就不贴出来了,有兴趣的翻翻上一章的内容)
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
// 清除取消的节点
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
// 线程中断相关
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
// AbstractQueuedSynchronizer.ConditionObject.addConditionWaiter
private Node addConditionWaiter() {
Node t = lastWaiter;
// 如果条件队列的尾节点已取消,从头节点开始清除所有已取消的节点
if (t != null && t.waitStatus != Node.CONDITION) {
unlinkCancelledWaiters();
// 重新获取尾节点
t = lastWaiter;
}
// 新建一个节点,它的等待状态是CONDITION
Node node = new Node(Thread.currentThread(), Node.CONDITION);
// 如果尾节点为空,则把新节点赋值给头节点(相当于初始化队列)
// 否则把新节点赋值给尾节点的nextWaiter指针
if (t == null)
firstWaiter = node;
else
t.nextWaiter = node;
// 尾节点指向新节点
lastWaiter = node;
// 返回新节点
return node;
}
// AbstractQueuedSynchronizer.fullyRelease
final int fullyRelease(Node node) {
boolean failed = true;
try {
// 获取状态变量的值,重复获取锁,这个值会一直累加
// 所以这个值也代表着获取锁的次数
int savedState = getState();
// 一次性释放所有获得的锁
if (release(savedState)) {
failed = false;
// 返回获取锁的次数
return savedState;
} else {
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
node.waitStatus = Node.CANCELLED;
}
}
// AbstractQueuedSynchronizer.isOnSyncQueue
final boolean isOnSyncQueue(Node node) {
// 如果等待状态是CONDITION,或者前一个指针为空,返回false
// 说明还没有移到AQS的队列中
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
// 如果next指针有值,说明已经移到AQS的队列中了
if (node.next != null) // If has successor, it must be on queue
return true;
// 从AQS的尾节点开始往前寻找看是否可以找到当前节点,找到了也说明已经在AQS的队列中了
return findNodeFromTail(node);
}

这里有几个难理解的点:

(1)Condition的队列和AQS的队列不完全一样;

AQS的队列头节点是不存在任何值的,是一个虚节点;

Condition的队列头节点是存储着实实在在的元素值的,是真实节点。

(2)各种等待状态(waitStatus)的变化;

首先,在条件队列中,新建节点的初始等待状态是CONDITION(-2);

其次,移到AQS的队列中时等待状态会更改为0(AQS队列节点的初始等待状态为0);

然后,在AQS的队列中如果需要阻塞,会把它上一个节点的等待状态设置为SIGNAL(-1);

最后,不管在Condition队列还是AQS队列中,已取消的节点的等待状态都会设置为CANCELLED(1);

另外,后面我们在共享锁的时候还会讲到另外一种等待状态叫PROPAGATE(-3)。

(3)相似的名称;

AQS中下一个节点是next,上一个节点是prev;

Condition中下一个节点是nextWaiter,没有上一个节点。

如果弄明白了这几个点,看懂上面的代码还是轻松加愉快的,如果没弄明白,彤哥这里指出来了,希望您回头再看看上面的代码。

下面总结一下await()方法的大致流程:

(1)新建一个节点加入到条件队列中去;

(2)完全释放当前线程占有的锁;

(3)阻塞当前线程,并等待条件的出现;

(4)条件已出现(此时节点已经移到AQS的队列中),尝试获取锁;

也就是说await()方法内部其实是先释放锁->等待条件->再次获取锁的过程。

condition.signal()方法

condition.signal()方法通知条件已经出现。

// AbstractQueuedSynchronizer.ConditionObject.signal
public final void signal() {
// 如果不是当前线程占有着锁,调用这个方法抛出异常
// 说明signal()也要在获取锁之后执行
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 条件队列的头节点
Node first = firstWaiter;
// 如果有等待条件的节点,则通知它条件已成立
if (first != null)
doSignal(first);
}
// AbstractQueuedSynchronizer.ConditionObject.doSignal
private void doSignal(Node first) {
do {
// 移到条件队列的头节点往后一位
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
// 相当于把头节点从队列中出队
first.nextWaiter = null;
// 转移节点到AQS队列中
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
// AbstractQueuedSynchronizer.transferForSignal
final boolean transferForSignal(Node node) {
// 把节点的状态更改为0,也就是说即将移到AQS队列中
// 如果失败了,说明节点已经被改成取消状态了
// 返回false,通过上面的循环可知会寻找下一个可用节点
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
// 调用AQS的入队方法把节点移到AQS的队列中
// 注意,这里enq()的返回值是node的上一个节点,也就是旧尾节点
Node p = enq(node);
// 上一个节点的等待状态
int ws = p.waitStatus;
// 如果上一个节点已取消了,或者更新状态为SIGNAL失败(也是说明上一个节点已经取消了)
// 则直接唤醒当前节点对应的线程
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
// 如果更新上一个节点的等待状态为SIGNAL成功了
// 则返回true,这时上面的循环不成立了,退出循环,也就是只通知了一个节点
// 此时当前节点还是阻塞状态
// 也就是说调用signal()的时候并不会真正唤醒一个节点
// 只是把节点从条件队列移到AQS队列中
return true;
}

signal()方法的大致流程为:

(1)从条件队列的头节点开始寻找一个非取消状态的节点;

(2)把它从条件队列移到AQS队列;

(3)且只移动一个节点;

注意,这里调用signal()方法后并不会真正唤醒一个节点,那么,唤醒一个节点是在啥时候呢?

还记得开头例子吗?倒回去再好好看看,signal()方法后,最终会执行lock.unlock()方法,此时才会真正唤醒一个节点,唤醒的这个节点如果曾经是条件节点的话又会继续执行await()方法“分界线”下面的代码。

结束了,仔细体会下^^

如果非要用一个图来表示的话,我想下面这个图可以大致表示一下(这里是用时序图画的,但是实际并不能算作一个真正的时序图哈,了解就好):

总结

(1)重入锁是指可重复获取的锁,即一个线程获取锁之后再尝试获取锁时会自动获取锁;

(2)在ReentrantLock中重入锁是通过不断累加state变量的值实现的;

(3)ReentrantLock的释放要跟获取匹配,即获取了几次也要释放几次;

(4)ReentrantLock默认是非公平模式,因为非公平模式效率更高;

(5)条件锁是指为了等待某个条件出现而使用的一种锁;

(6)条件锁比较经典的使用场景就是队列为空时阻塞在条件notEmpty上;

(7)ReentrantLock中的条件锁是通过AQS的ConditionObject内部类实现的;

(8)await()和signal()方法都必须在获取锁之后释放锁之前使用;

(9)await()方法会新建一个节点放到条件队列中,接着完全释放锁,然后阻塞当前线程并等待条件的出现;

(10)signal()方法会寻找条件队列中第一个可用节点移到AQS队列中;

(11)在调用signal()方法的线程调用unlock()方法才真正唤醒阻塞在条件上的节点(此时节点已经在AQS队列中);

(12)之后该节点会再次尝试获取锁,后面的逻辑与lock()的逻辑基本一致了。

彩蛋

为什么java有自带的关键字synchronized了还需要实现一个ReentrantLock呢?

首先,它们都是可重入锁;

其次,它们都默认是非公平模式;

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

时间: 2019-06-02

Java源码解析之可重入锁ReentrantLock

本文基于jdk1.8进行分析. ReentrantLock是一个可重入锁,在ConcurrentHashMap中使用了ReentrantLock. 首先看一下源码中对ReentrantLock的介绍.如下图.ReentrantLock是一个可重入的排他锁,它和synchronized的方法和代码有着相同的行为和语义,但有更多的功能.ReentrantLock是被最后一个成功lock锁并且还没有unlock的线程拥有着.如果锁没有被别的线程拥有,那么一个线程调用lock方法,就会成功获取锁并返回.

详解java并发之重入锁-ReentrantLock

前言 目前主流的锁有两种,一种是synchronized,另一种就是ReentrantLock,JDK优化到现在目前为止synchronized的性能已经和重入锁不分伯仲了,但是重入锁的功能和灵活性要比这个关键字多的多,所以重入锁是可以完全替代synchronized关键字的.下面就来介绍这个重入锁. 正文 ReentrantLock重入锁是Lock接口里最重要的实现,也是在实际开发中应用最多的一个,我这篇文章更接近实际开发的应用场景,为开发者提供直接上手应用.所以不是所有方法我都讲解,有些冷门

java ReentrantLock详解

介绍 ReentrantLock称为重入锁,比内部锁synchonized拥有更强大的功能,它可中断.可定时.设置公平锁 [注]使用ReentrantLock时,一定要释放锁,一般释放放到finnal里写. 提供以下重要的方法 lock():获得锁,如果锁已被占用,则等待 lockInterruptibly():获得锁,但有限响应中断 unlock():释放锁 tryLock():尝试获取锁.如果获得,返回true:否则返回false tryLock(long time, TimeUnit un

ReentrantLock源码详解--公平锁、非公平锁

问题 (1)重入锁是什么? (2)ReentrantLock如何实现重入锁? (3)ReentrantLock为什么默认是非公平模式? (4)ReentrantLock除了可重入还有哪些特性? 简介 Reentrant = Re + entrant,Re是重复.又.再的意思,entrant是enter的名词或者形容词形式,翻译为进入者或者可进入的,所以Reentrant翻译为可重复进入的.可再次进入的,因此ReentrantLock翻译为重入锁或者再入锁. 重入锁,是指一个线程获取锁之后再尝试获

Android实现屏幕锁定源码详解

最近有朋友问屏幕锁定的问题,自己也在学习,网上找了下也没太详细的例子,看的资料书上也没有有关屏幕锁定程序的介绍,下个小决心,自己照着官方文档学习下,现在做好了,废话不多说,先发下截图,看下效果,需要注意的地方会加注释,有问题的朋友可以直接留言,我们共同学习交流,共同提高进步!直接看效果图: 一:未设置密码时进入系统设置的效果图如下: 二:设置密码方式预览: 三:密码解密效果图 四:九宫格解密时的效果图 下面来简单的看下源码吧,此处讲下,这个小DEMO也是临时学习下的,有讲的不明白的地方请朋友直接

Android context源码详解及深入分析

Android context详解 前言: Context都没弄明白,还怎么做Android开发? Activity mActivity =new Activity() 作为Android开发者,不知道你有没有思考过这个问题,Activity可以new吗?Android的应用程序开发采用Java语言,Activity本质上也是一个对象,那上面的写法有什么问题呢?估计很多人说不清道不明.Android程序不像Java程序一样,随便创建一个类,写个main()方法就能运行,Android应用模型是基

Java集合Stack源码详解

概要 学完Vector了之后,接下来我们开始学习Stack.Stack很简单,它继承于Vector.学习方式还是和之前一样,先对Stack有个整体认识,然后再学习它的源码:最后再通过实例来学会使用它. 第1部分 Stack介绍 Stack简介 Stack是栈.它的特性是:先进后出(FILO, First In Last Out). java工具包中的Stack是继承于Vector(矢量队列)的,由于Vector是通过数组实现的,这就意味着,Stack也是通过数组实现的,而非链表.当然,我们也可以

基于jdk1.8的Java源码详解 Integer

public final class Integer extends Number implements Comparable<Integer> Integer 由final修饰了,所以该类不能够被继承,同时 Integer 继承了Number类,因此可以将Integer转换成 int .double.float.long.byte和short类型的数据,另外,也实现了comparable接口,因此Integer类也可以进行自然排序. 构造方法只有两个: public Integer(int

微信 小程序前端源码详解及实例分析

微信小程序前端源码逻辑和工作流 看完微信小程序的前端代码真的让我热血沸腾啊,代码逻辑和设计一目了然,没有多余的东西,真的是大道至简. 废话不多说,直接分析前端代码.个人观点,难免有疏漏,仅供参考. 文件基本结构: 先看入口app.js,app(obj)注册一个小程序.接受一个 object 参数,其指定小程序的生命周期函数等.其他文件可以通过全局方法getApp()获取app实例,进而直接调用它的属性或方法,例如(getApp().globalData) //app.js App({ onLau

JS小游戏之宇宙战机源码详解

本文实例讲述了JS小游戏的宇宙战机源码,分享给大家供大家参考.具体介绍如下: 一.游戏介绍: 这是一款飞行射击游戏,纵向,共六关. 二.游戏需求: 1.战机可发射子弹,子弹可通过获取道具升级. 2.战机可放bomb,可获取道具增加数量. 3.战机可蓄力攻击. 4.道具有三种,分别是升级子弹,增加bomb数量,增加战机数量. 5.每关音乐不同. 6.战机被击落后再进入战场,有保护状态. 7.敌机AI设计. 游戏运行如下图所示: 完整实例代码点击此处本站下载. 三.Javascript源码部分: /

话说Spring Security权限管理(源码详解)

最近项目需要用到Spring Security的权限控制,故花了点时间简单的去看了一下其权限控制相关的源码(版本为4.2). AccessDecisionManager spring security是通过AccessDecisionManager进行授权管理的,先来张官方图镇楼. AccessDecisionManager AccessDecisionManager 接口定义了如下方法: //调用AccessDecisionVoter进行投票(关键方法) void decide(Authent

JS小游戏之仙剑翻牌源码详解

本文实例讲述了JS小游戏的仙剑翻牌源码,是一款非常优秀的游戏源码.分享给大家供大家参考.具体如下: 一.游戏介绍: 这是一个翻牌配对游戏,共十关. 1.游戏随机从42张牌中抽取9张进行游戏,每组为2张相同的牌,共18张牌. 2.连续翻到两张相同的为胜利,当9组全部翻到则过关.如不是翻到连续两张相同的,则需要重新翻. 3.游戏共有10关,在规定时间内通过为挑战成功. 4.如果某关在规定时间内没有通过,则会从当前关继续游戏. 5.游戏中的卡牌图片与音乐均为大宇公司所有. 6.需要支持html5的浏览