浅聊一下，可中断锁（ReentrantLock）

前言

今天早上上厕所，上的我痔疮犯了，屁股一坐下去就感觉一根针在刺我，得的是外痔，之前还坚持用痔疮膏来着，但是感觉涂药的那个姿势以及位置我实在无法忍受，就把它给断了，到头来还是屁股糟了罪，

什么是可中断锁？

再说起 ReentrantLock 的时候可能很多人第一时间想到的是公平、非公平锁，但是 ReentrantLock 丰富的 api 可不止于此哦，可中断锁顾名思义，就是在竞争锁等待的时间太久，我们开发人员可以调用 interrupt（英特入谱特）方法让 lockInterruptibly （加锁可中断）方法抛出异常，让线程主动退出等待的过程，去做别的事情。

可中断锁应用

threadOne 进行 lockInterruptibly 加锁操作，由于锁一直被 threadOne 占用，当 threadTwo 开始进行 lockInterruptibly 加锁的时候，由于锁还在 threadOne 这，threadOne 会一直处于一个等待的状态，如果 threadOne 一直没有调用 unlock 方法，那么 threadTwo 会一直休眠，直至等到 unlock、或者 threadOne.interrupt() 方法才会再次被唤醒进行工作，而 ReentrantLock 显然也是考虑到了这一点，在 lockInterruptibly 方法里面，如果线程被唤醒后，会对线程的中断状态进行一个判断，如果线程被中断了，则会抛出一个异常，这样一来，就避免了 threadTwo 一直等待的现象出现了。

lockInterruptibly 源码剖析

点进入口中可以看到，是利用了 sync 里面的一个类实现的

而 sync 继承了 AQS （AbstractQueuedSynchronizer），哦吼又是借助 AQS 实现的。接下来我们只需分析 AQS 中的 acquireInterruptibly 方法就好了。

可以看到，如果是一个中断状态的线程去使用 lockInterruptibly 方法会直接抛出异常的，开发的时候要注意！里面的 tryAcquire 方法在我们分析公平、非公平锁的时候就已经分析过了，不做剖析。可以点击 ReentrantLock源码探究、探究公平锁与非公平锁背后的奥秘 进行阅读。那么就只剩下 doAcquireInterruptibly 了。

doAcquireInterruptibly 源码剖析

这段代码其实也在 ReentrantLock源码探究、探究公平锁与非公平锁背后的奥秘 这篇文章里面分析过了。和 AQS 中的 acquireQueued 这个方法逻辑一样，唯一有区别的地方就是，线程被唤醒后 doAcquireInterruptibly 会直接抛出一个异常，而 acquireQueued 则不会。

下面我贴一张我自己的截图，方便日后阅读～～～～～，到此 ReentrantLock 是可中断锁的秘密已经解开了。

线程中的 interrupt、park、interrupted、isInterrupted 是什么？

一个简单的小例子直观感受一下，threadOne 里面调用 parkAndCheckInterrupt 方法进行休眠（阻塞）线程的操作，然后等待被唤醒，过了 10 秒钟后 threadOne 自己调用了 interrupt 方法，将 park 休眠状态下的自己给唤醒了。值得一提的是 interrupted 方法被调用后，线程的中断状态会立即反转一次，之后看自己的中断状态即为反转后的状态。而且唤醒 threadOne 的方式不止一种，还可以使用 LockSupport.unpark(threadOne);

运行结果