【并发编程】 --- Reentrantlock源码解析5:再探不可中断性 + 线程unpark后诡异的Thread.interrupted()判断

文章目录

  • 1 想要读懂这篇文章必须要拥有的前置知识
  • 2 想写这篇文章的原因
  • 3 困扰我很久的Reentrantlock源代码1 --- 貌似无用的变量failed
  • 4 困扰我很久的Reentrantlock源代码2 --- unpark后为啥要来个Thread.interrupted();
  • 5 小记

源码地址:https://github.com/nieandsun/concurrent-study.git


1 想要读懂这篇文章必须要拥有的前置知识

《【并发编程】 — synchronized/ReentrantLock两大特性(可重入性和不可中断性)介绍》
《【并发编程】— interrupt、interrupted和isInterrupted使用详解》
《【并发编程】 — Reentrantlock源码解析2:公平锁加锁过程超详细解析》
《【并发编程】 — Reentrantlock源码解析3:公平锁释放锁过程超详细解析》


2 想写这篇文章的原因

下面这幅图是我在文章《【并发编程】 — Reentrantlock源码解析3:公平锁释放锁过程超详细解析》中给出的一幅图。
【并发编程】 --- Reentrantlock源码解析5:再探不可中断性 + 线程unpark后诡异的Thread.interrupted()判断_第1张图片
不知道大家对这幅图中的代码有没有疑惑??? —> 说实话我有,而且困扰了我很久很久!!!
本篇文章将主要针对我困扰的问题进行讨论,并给出我自认为可以自圆其说的解释!!!


3 困扰我很久的Reentrantlock源代码1 — 貌似无用的变量failed

我们先来看一下1中红色标号为5的代码。

我的疑问如下:
【并发编程】 --- Reentrantlock源码解析5:再探不可中断性 + 线程unpark后诡异的Thread.interrupted()判断_第2张图片
可能有人会说:

在try那块代码里 failed = false;这句代码之前有可能会抛出异常,如果抛了异常之后就会走finally代码块,那个时候failed还是初始值true ,那这个逻辑就有意义了。 —> 这句话说的一点没错,但是这是一种怎样的情况呢???

假如你恰巧看过这篇文章《【并发编程】 — synchronized/ReentrantLock两大特性(可重入性和不可中断性)介绍》,那我觉得你应该是可以回答上来的:

使用Reentrantlock锁,当某个线程正在被park时,使用stop方法中断此线程,就正好是这种情况。


相信大家都知道使用stop方法中断某个线程,会直接释放掉本线程所持有的所有资源,举个简单的栗子来说,假如我们正在使用某个线程下载电影,如果该线程通过stop进行中断,则原来下载的内容将全部丢失,因此可以简单将其理解为“暴力中断”(自己发明的词,见笑☺),只要调用了,就不可能恢复了 —》 应该正是基于这个原因,JDK官方将其@Deprecated了。

但是万一有些业务确实就需要这种“暴力中断”呢???

看过 《【并发编程】 — synchronized/ReentrantLock两大特性(可重入性和不可中断性)介绍》这篇文章的应该知道,

synchronized关键字的处理逻辑是,假如线程被park了,即使使用stop进行“暴力中断”, 对不起, 没法给你立即中断 —》 但是当你有了抢锁资格后,就立即给你中断!!!

仔细想想这个逻辑 ,是不是一个挺操蛋的逻辑??? 我都采用暴力中断了,你还不给我立即中断,而当我有抢锁资格了,我肯定这时候就大概率不想中断了啊,你到立刻给我来个暴力中断!!!

或许Doug Lea大神也觉得这个逻辑比较操蛋吧。。。所以人家在Reentrantlock中做了改进!!!

要很详整的说出来具体的改进应该还要把cancelAcquire的源码给搬出来,但是这里我不打算搬出来了,所以只是简单的,从比较宏观的角度去阐述一下(当然私底下,我已经打过n遍断点验证过我的观点了,有兴趣的可以自己亲自动手试试!!!)。


假设Node链表中有t2和t3在排队等着抢锁,其结构如下,这时候突然想用stop()方法“暴力中断”t2线程。
【并发编程】 --- Reentrantlock源码解析5:再探不可中断性 + 线程unpark后诡异的Thread.interrupted()判断_第3张图片

在不看源码的情况下,我觉得你仔细想想应该也能想出个一二来。 首先我们应该知道既然t2要被“暴力中断”了,那这个线程说的直白点就直接相当于没有了。。。 那该线程在Node链表里肯定也就没必要存在了吧; —》 反过来想,假若我不处理Node链表,在解锁时发现Node链表里竟然除了head外还有一个线程为null的Node,你是不是感觉也很不可理解??? —> 想到这里其实你就知道Doug Lea大神会干什么了 —》 没错,将被stop的线程从Node链表里出队。

以上图而言Doug Lea大神的逻辑基本如下:

  • (1)既然stop了,线程会被暴力中断,但是因为有finally关键字,所以会进入到cancelAcquire()方法
  • (2)将线程t2对应的节点的waitStatus置为1
  • (3)unpark线程t3 ,让线程t3去自旋 —》 由文章《【并发编程】 — Reentrantlock源码解析2:公平锁加锁过程超详细解析》可知,由于线程t2所在Node的waitStatus此时为1,因此会在t3自旋时,将其从Node链表中给踢出去 —》 由此便完成了被stop的线程t2所在节点的出队。

4 困扰我很久的Reentrantlock源代码2 — unpark后为啥要来个Thread.interrupted();

这块代码真是困扰了很久很久很久!!!! - > 甚至都有时候都怀疑自己太钻死牛角尖了!!!

昨天非常有幸,在B站看到了子路老师的讲解,后又思考良久,甚至找子路老师聊了该问题,终于找到了一个可以自圆其说的原因!!!

【并发编程】 --- Reentrantlock源码解析5:再探不可中断性 + 线程unpark后诡异的Thread.interrupted()判断_第4张图片
如果看懂了我这篇文章《【并发编程】— interrupt、interrupted和isInterrupted使用详解》再看上面这张图,你脑子要TMD崩溃!!!

为啥这样说呢???

我们这里直接看线程t被打断的情况,他做了个啥啊,这是!!! —》 先判断一下是否被打断(这里要注意一下interrupted和isInterrupted的区别,但是对于这里不重要!!!) —》如果是 —》我再打断一次

  • 而我想大家应该都知道使用interrupt做打断,其实就相当于皇帝在某个妃子房间里玩耍,突然某个太监在外面喊:万岁,注意龙体,该去休息了。---》 但是皇帝到底停不停,全由它自己说了算!!!
  • 那TMD就让人疑惑了,Doug Lea这是要干啥啊,闲的蛋疼?在中间传个话???
  • 如果它啥事不做,不也是这样么???—》 也就是说上面的流程不是和下面的流程一个样么???— 而且下面是不是效率还更高一些???

【并发编程】 --- Reentrantlock源码解析5:再探不可中断性 + 线程unpark后诡异的Thread.interrupted()判断_第5张图片
那Doug Lea为啥要这样搞呢???


研究了n天后,结合子路老师的解答,我给出的答案是为了代码格式的统一,以及某些锁少写几行重复代码!!!

首先来看一下用到parkAndCheckInterrupt() 这个方法的所有方法:

  • acquireQueued方法 — 独占锁自旋主要逻辑
  • doAcquireInterruptibly方法 — 可打断的独占锁自旋主要逻辑
  • doAcquireShared方法 — 共享锁自旋主要逻辑
  • doAcquireSharedInterruptibly方法— 可打断的共享锁自旋主要逻辑

这算不算格式上的统一??? —》 有兴趣的可以留言交流!!!


其次来简单看一下acquireQueueddoAcquireInterruptibly两个方法的简单比较:
【并发编程】 --- Reentrantlock源码解析5:再探不可中断性 + 线程unpark后诡异的Thread.interrupted()判断_第6张图片

这算不算在某些锁少写几行重复代码 —》 有兴趣的可以留言交流!!!


5 小记

有时候感觉自己像个傻子!!! 总习惯于沿着一个方向不停的钻钻钻!!!
上学时老师说我适合搞研究,能做事, 但又不适合,做的太多,研究的太深, 但是却总不发文章。
于是思考了将近半年,下定决心要去工作,所幸手头的工作都比较简单 。

因此想快速搭建起自己的知识体系,但是发现自己还是会时不时的钻钻钻!!!—》于是学的东西慢且少,而且越学越觉得不懂的越多!!! —》 所以¥¥¥ 。。。

唉!!!唉!!!唉!!!


end!!!

你可能感兴趣的:(并发编程)