摘要:我们知道,这个函数将返回当前正在执行的线程的中断状态,并清除它。注意,中断对线程来说只是一个建议,一个线程被中断只是其中断状态被设为线程可以选择忽略这个中断,中断一个线程并不会影响线程的执行。
前言
系列文章目录
上一篇文章 我们逐行分析了独占锁的获取操作, 本篇文章我们来看看独占锁的释放。如果前面的锁的获取流程你已经趟过一遍了, 那锁的释放部分就很简单了, 这篇文章我们直接开始看源码.
开始之前先提一句, JAVA的内置锁在退出临界区之后是会自动释放锁的, 但是ReentrantLock这样的显式锁是需要自己显式的释放的, 所以在加锁之后一定不要忘记在finally块中进行显式的锁释放:
Lock lock = new ReentrantLock(); ... lock.lock(); try { // 更新对象 //捕获异常 } finally { lock.unlock(); }
一定要记得在 finally 块中释放锁! ! !
一定要记得在 finally 块中释放锁! ! !
一定要记得在 finally 块中释放锁! ! !
由于锁的释放操作对于公平锁和非公平锁都是一样的, 所以, unlock的逻辑并没有放在 FairSync 或 NonfairSync 里面, 而是直接定义在 ReentrantLock类中:
public void unlock() { sync.release(1); }
由于释放锁的逻辑很简单, 这里就不画流程图了, 我们直接看源码:
releaserelease方法定义在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; }
可以看出, 相比获取锁的acquire方法, 释放锁的过程要简单很多, 它只涉及到两个子函数的调用:
tryRelease(arg)
该方法由继承AQS的子类实现, 为释放锁的具体逻辑
unparkSuccessor(h)
唤醒后继线程
下面我们分别分析这两个子函数
tryReleasetryRelease方法由ReentrantLock的静态类Sync实现:
多嘴提醒一下, 能执行到释放锁的线程, 一定是已经获取了锁的线程(这不废话嘛!)
另外, 相比获取锁的操作, 这里并没有使用任何CAS操作, 也是因为当前线程已经持有了锁, 所以可以直接安全的操作, 不会产生竞争.
protected final boolean tryRelease(int releases) { // 首先将当前持有锁的线程个数减1(回溯到调用源头sync.release(1)可知, releases的值为1) // 这里的操作主要是针对可重入锁的情况下, c可能大于1 int c = getState() - releases; // 释放锁的线程当前必须是持有锁的线程 if (Thread.currentThread() != getExclusiveOwnerThread()) throw new IllegalMonitorStateException(); // 如果c为0了, 说明锁已经完全释放了 boolean free = false; if (c == 0) { free = true; setExclusiveOwnerThread(null); } setState(c); return free; }
是不是很简单? 代码都是自解释的, LZ就不多嘴了.
unparkSuccessorpublic final boolean release(int arg) { if (tryRelease(arg)) { Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false; }
锁成功释放之后, 接下来就是唤醒后继节点了, 这个方法同样定义在AQS中.
值得注意的是, 在成功释放锁之后(tryRelease 返回 true之后), 唤醒后继节点只是一个 "附加操作", 无论该操作结果怎样, 最后 release操作都会返回 true.
事实上, unparkSuccessor 函数也不会返回任何值
接下来我们就看看unparkSuccessor的源码:
private void unparkSuccessor(Node node) { int ws = node.waitStatus; // 如果head节点的ws比0小, 则直接将它设为0 if (ws < 0) compareAndSetWaitStatus(node, ws, 0); // 通常情况下, 要唤醒的节点就是自己的后继节点 // 如果后继节点存在且也在等待锁, 那就直接唤醒它 // 但是有可能存在 后继节点取消等待锁 的情况 // 此时从尾节点开始向前找起, 直到找到距离head节点最近的ws<=0的节点 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; // 注意! 这里找到了之并有return, 而是继续向前找 } // 如果找到了还在等待锁的节点,则唤醒它 if (s != null) LockSupport.unpark(s.thread); }
在上一篇文章分析 shouldParkAfterFailedAcquire 方法的时候, 我们重点提到了当前节点的前驱节点的 waitStatus 属性, 该属性决定了我们是否要挂起当前线程, 并且我们知道, 如果一个线程被挂起了, 它的前驱节点的 waitStatus值必然是Node.SIGNAL.
在唤醒后继节点的操作中, 我们也需要依赖于节点的waitStatus值.
下面我们仔细分析 unparkSuccessor函数:
首先, 传入该函数的参数node就是头节点head, 并且条件是
h != null && h.waitStatus != 0
h!=null 我们容易理解, h.waitStatus != 0是个什么意思呢?
我不妨逆向来思考一下, waitStatus在什么条件下等于0? 从上一篇文章到现在, 我们发现之前给 waitStatus赋值过的地方只有一处, 那就是shouldParkAfterFailedAcquire 函数中将前驱节点的 waitStatus设为Node.SIGNAL, 除此之外, 就没有了.
然而, 真的没有了吗???
其实还有一处, 那就是新建一个节点的时候, 在addWaiter 函数中, 当我们将一个新的节点添加进队列或者初始化空队列的时候, 都会新建节点 而新建的节点的waitStatus在没有赋值的情况下都会初始化为0.
所以当一个head节点的waitStatus为0说明什么呢, 说明这个head节点后面没有在挂起等待中的后继节点了(如果有的话, head的ws就会被后继节点设为Node.SIGNAL了), 自然也就不要执行 unparkSuccessor 操作了.
另外一个有趣的问题是, 为什么要从尾节点开始逆向查找, 而不是直接从head节点往后正向查找, 这样只要正向找到第一个, 不就可以停止查找了吗?
首先我们要看到,从后往前找是基于一定条件的:
if (s == null || s.waitStatus > 0)
即后继节点不存在,或者后继节点取消了排队,这一条件大多数条件下是不满足的。因为虽然后继节点取消排队很正常,但是通过上一篇我们介绍的shouldParkAfterFailedAcquire方法可知,节点在挂起前,都会给自己找一个waitStatus状态为SIGNAL的前驱节点,而跳过那些已经cancel掉的节点。
所以,这个从后往前找的目的其实是为了照顾刚刚加入到队列中的节点,这就牵涉到我们上一篇特别介绍的“尾分叉”了:
private Node addWaiter(Node mode) { Node node = new Node(Thread.currentThread(), mode); //将当前线程包装成Node Node pred = tail; // 如果队列不为空, 则用CAS方式将当前节点设为尾节点 if (pred != null) { node.prev = pred; //step 1, 设置前驱节点 if (compareAndSetTail(pred, node)) { // step2, 将当前节点设置成新的尾节点 pred.next = node; // step 3, 将前驱节点的next属性指向自己 return node; } } enq(node); return node; }
如果你仔细看上面这段代码, 可以发现节点入队不是一个原子操作, 虽然用了compareAndSetTail操作保证了当前节点被设置成尾节点,但是只能保证,此时step1和step2是执行完成的,有可能在step3还没有来的及执行到的时候,我们的unparkSuccessor方法就开始执行了,此时pred.next的值还没有被设置成node,所以从前往后遍历的话是遍历不到尾节点的,但是因为尾节点此时已经设置完成,node.prev = pred操作也被执行过了,也就是说,如果从后往前遍历的话,新加的尾节点就可以遍历到了,并且可以通过它一直往前找。
所以总结来说,之所以从后往前遍历是因为,我们是处于多线程并发的条件下的,如果一个节点的next属性为null, 并不能保证它就是尾节点(可能是因为新加的尾节点还没来得及执行pred.next = node), 但是一个节点如果能入队, 则它的prev属性一定是有值的,所以反向查找一定是最精确的。
最后, 在调用了 LockSupport.unpark(s.thread) 也就是唤醒了线程之后, 会发生什么呢?
当然是回到最初的原点啦, 从哪里跌倒(被挂起)就从哪里站起来(唤醒)呗:
private final boolean parkAndCheckInterrupt() { LockSupport.park(this); // 喏, 就是在这里被挂起了, 唤醒之后就能继续往下执行了 return Thread.interrupted(); }
那接下来做什么呢?
还记得我们上一篇在讲“锁的获取”的时候留的问题吗? 如果线程从这里唤醒了,它将接着往下执行。
注意,这里有两个线程:
一个是我们这篇讲的线程,它正在释放锁,并调用了LockSupport.unpark(s.thread) 唤醒了另外一个线程;
而这个另外一个线程,就是我们上一节讲的因为抢锁失败而被阻塞在LockSupport.park(this)处的线程。
我们再倒回上一篇结束的地方,看看这个被阻塞的线程被唤醒后,会发生什么。从上面的代码可以看出,他将调用 Thread.interrupted()并返回。
我们知道,Thread.interrupted()这个函数将返回当前正在执行的线程的中断状态,并清除它。接着,我们再返回到parkAndCheckInterrupt被调用的地方:
final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return interrupted; } // 我们在这里!在这里!!在这里!!! // 我们在这里!在这里!!在这里!!! // 我们在这里!在这里!!在这里!!! if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } }
具体来说,就是这个if语句
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true;
可见,如果Thread.interrupted()返回true,则 parkAndCheckInterrupt()就返回true, if条件成立,interrupted状态将设为true;
如果Thread.interrupted()返回false, 则 interrupted 仍为false。
再接下来我们又回到了for (;;) 死循环的开头,进行新一轮的抢锁。
假设这次我们抢到了,我们将从 return interrupted处返回,返回到哪里呢? 当然是acquireQueued的调用处啦:
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }
我们看到,如果acquireQueued的返回值为true, 我们将执行 selfInterrupt():
static void selfInterrupt() { Thread.currentThread().interrupt(); }
而它的作用,就是中断当前线程。
绕了这么一大圈,到最后还是中断了当前线程,到底是在干嘛呢?
其实这一切的原因都在于:
我们并不知道线程被唤醒的原因。
具体来说,当我们从LockSupport.park(this)处被唤醒,我们并不知道是因为什么原因被唤醒,可能是因为别的线程释放了锁,调用了 LockSupport.unpark(s.thread),也有可能是因为当前线程在等待中被中断了,因此我们通过Thread.interrupted()方法检查了当前线程的中断标志,并将它记录下来,在我们最后返回acquire方法后,如果发现当前线程曾经被中断过,那我们就把当前线程再中断一次。
为什么要这么做呢?
从上面的代码中我们知道,即使线程在等待资源的过程中被中断唤醒,它还是会不依不饶的再抢锁,直到它抢到锁为止。也就是说,它是不响应这个中断的,仅仅是记录下自己被人中断过。
最后,当它抢到锁返回了,如果它发现自己曾经被中断过,它就再中断自己一次,将这个中断补上。
注意,中断对线程来说只是一个建议,一个线程被中断只是其中断状态被设为true, 线程可以选择忽略这个中断,中断一个线程并不会影响线程的执行。
线程中断是一个很重要的概念,这个我们以后有机会再细讲。(已成文,参见Thread类源码解读(3)——线程中断interrupt)
最后再小小的插一句,事实上在我们从return interrupted;处返回时并不是直接返回的,因为还有一个finally代码块:
finally { if (failed) cancelAcquire(node); }
它做了一些善后工作,但是条件是failed为true,而从前面的分析中我们知道,要从for(;;)中跳出来,只有一种可能,那就是当前线程已经拿到了锁,因为整个争锁过程我们都是不响应中断的,所以不可能有异常抛出,既然是拿到了锁,failed就一定是true,所以这个finally块在这里实际上并没有什么用,它是为响应中断式的抢锁所服务的,这一点我们以后有机会再讲。
(完)
查看更多系列文章:系列文章目录
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/76474.html
摘要:为了避免一篇文章的篇幅过长,于是一些比较大的主题就都分成几篇来讲了,这篇文章是笔者所有文章的目录,将会持续更新,以给大家一个查看系列文章的入口。 前言 大家好,笔者是今年才开始写博客的,写作的初衷主要是想记录和分享自己的学习经历。因为写作的时候发现,为了弄懂一个知识,不得不先去了解另外一些知识,这样以来,为了说明一个问题,就要把一系列知识都了解一遍,写出来的文章就特别长。 为了避免一篇...
摘要:而对于共享锁而言,由于锁是可以被共享的,因此它可以被多个线程同时持有。换句话说,如果一个线程成功获取了共享锁,那么其他等待在这个共享锁上的线程就也可以尝试去获取锁,并且极有可能获取成功。 前言 前面两篇我们以ReentrantLock为例了解了AQS独占锁的获取与释放,本篇我们来看看共享锁。由于AQS对于共享锁与独占锁的实现框架比较类似,因此如果你搞定了前面的独占锁模式,则共享锁也就很...
摘要:本篇我们将以的公平锁为例来详细看看使用获取独占锁的流程。本文中的源码基于。由于本篇我们分析的是独占锁,同一时刻,锁只能被一个线程所持有。由于在整个抢锁过程中,我们都是不响应中断的。 前言 AQS(AbstractQueuedSynchronizer)是JAVA中众多锁以及并发工具的基础,其底层采用乐观锁,大量使用了CAS操作, 并且在冲突时,采用自旋方式重试,以实现轻量级和高效地获取锁...
摘要:前言本篇文章是基于线程间的同步与通信和这篇文章写的,在那篇文章中,我们分析了接口所定义的方法,本篇我们就来看看对于接口的这些接口方法的具体实现。因此,条件队列在出队时,线程并不持有锁。 前言 本篇文章是基于线程间的同步与通信(4)——Lock 和 Condtion 这篇文章写的,在那篇文章中,我们分析了Condition接口所定义的方法,本篇我们就来看看AQS对于Condition接口...
阅读 1810·2023-04-25 14:49
阅读 3083·2021-09-30 09:47
阅读 3061·2021-09-06 15:00
阅读 2193·2019-08-30 13:16
阅读 1413·2019-08-30 10:48
阅读 2638·2019-08-29 15:11
阅读 1206·2019-08-26 14:06
阅读 1620·2019-08-26 13:30