LockSupport与线程中断机制_locksupport 是如何处理中断的-优快云博客

在这里插入图片描述

线程中断机制

首先，一个线程不应该由其他线程来强制中断或停止，而是应该由线程自己自行停止，自己来决定自己的命运。所以，Thread.stop,Thread.suspend, Thread.resume都已经被废弃了。

其次，在Java中没有办法立即停止一条线程，然而停止线程却显得尤为重要，如取消一个耗时操作。
因此，Java提供了一种用于停止线程的协商机制-一中断，也即中断标识协商机制。

中断只是一种协作协商机制，Java没有给中断增加任何语法，中断的过程完全需要程序员自己实现。若要中断一个线程，你需要手动调用该线程的interrupt方法，该方法也仅仅是将线程对象的中断标识设成tnue;接着你需要自己写代码不断地检测当前线程的标识位，如果为true，表示的线程请求这条线程中断，此时究竟该做什么需要你自己写代码实现。

每个线程对象中都有一个中断标识位，用于表示线程是否被中断;该标识位为true表示中断，为false表示未中断;通过调用线程对象的interrupt方法将该线程的标识位设为tue;可以在别的线程中调用，也可以在自己的线程中调用。

中断机制三大方法

在这里插入图片描述

public void interrupt()

实例方法interrupt()仅仅是设置线程的中断状态为true，发起一个协商而不会立刻停止线程

public static boolean interrupted()

静态方法，Thread.interrupted();判断线程是否被中断并清除当前中断状态。

这个方法做了两件事：
1、返回当前线程的中断状态，测试当前线程是否已被中断
2、将当前线程的中断状态清零并重新设置为false，清理线程的中断状态

public boolean interrupted()

判断当前线程是否被中断(通过检查中断标志位)

如何中断运行中的线程？

有三种方法

volatile变量实现（volatile的可见性）
AtomicBoolean实现
Thread类自带中断api实现（本文着重讲的中断机制）

volatile变量实现中断

在这里插入图片描述

AtomicBoolean的原子性实现

在这里插入图片描述

interrupt的api实现

在这里插入图片描述
具体来说，当对一个线程，调用interrupt()时:
① 如果线程处于正常活动状蠢，那么会将该线程的中断标志设置为true，仅此而己。
被设置中断标志的线程将继续正常运行，不受影响。
所以，interrupt()并不能真正的中断线程，需要被调用的线程自己进行配合才行。
②)如果线程处于被阻塞状态(例如处于sleep,wait,join 等状态)，在别的线程中调用当前线程对象的interupt方法,那么线程将立即退出被阻察状态，并抛出一个InterruptedException异常。

中断线程后，会立马停止吗？

结论：不会
在这里插入图片描述

所以设置为中断后，不会立马停止，会继续执行，把线程的中断停止权力交给线程本身，其他线程不能操作其他线程的直接中断

在这里还有个额外需要注意的问题，如果在t1线程后正在运行，但是后面代码有sleep的逻辑，在sleep后面线程申请t1线程的interrup时，会死循环，需要在sleep的catch里面添加对该线程的interrupt，原因是会清除状态，恢复到false并抛出InterruptedException
在这里插入图片描述

LockSupport

LockSupport是JUC下locks包的一个类，是Lock功能的扩张和支撑
官方介绍是：用于创建锁和其他同步类的基本线程阻塞原语
在这里插入图片描述
该类与使用它的每个线程关联一个许可证（在Semaphore类的意义上）。如果许可证可用，将立即返回park ，并在此过程中消费; 否则可能会阻止。如果尚未提供许可，则致电unpark获得许可。

由此可得出此类比较重要的方法是park和unpark，且许可证最多只有一个
在这里插入图片描述

线程唤醒的方法

在这里用线程唤醒的方法来引出，LockSupport的由来

Object的wait和notify方法

以下代码正常运行
在这里插入图片描述
异常情况，注释锁就会报错，所以如果要使用wait和notify必须被包在synchronized里面，且成对出现

异常情况，先执行notify再执行wait，那么就无法被唤醒，wait和notify顺序需要严格遵循
在这里插入图片描述

Condition的await和signal方法

正常情况
在这里插入图片描述
异常情况，注释lock锁，所以lock和unlock不能缺少，线程等待和唤醒需要先获取锁

异常情况，先signal后await，一直无法被唤醒，执行顺序也很重要

LockSupport可以堵塞当前线程以及唤醒指定被堵塞的线程

上述两个对象Object和Condition使用的限制条件：

线程需要先获取锁，必须在锁块里（synchronized或lock）中
必须要先等待后唤醒，线程才能被唤醒

正常情况
在这里插入图片描述

先通知后唤醒，不会出问题
在这里插入图片描述
异常情况，多个park和unpark会导致堵塞问题，因为官方说了许可证不会累积，只有一个

总结

LockSupport是用来创建锁和其他同步类的基本线程阻塞原语。
LockSupport是一个线程阻塞工具类，所有的方法都是静态方法，可以让线程在任意位置阻塞，阻塞之后也有对应的唤醒方法。归根结底，LockSupport调用的Unsafe中的native代码。

LockSupport 提供park()和unpark()方法实现阻塞线程和解除线程阻塞的过程
LockSupport和每个使用它的线程都有一个许可(permit)关联。
每个线程都有一个相关的permit,permit最多只有一个，重复调用unpark也不会积累凭证。

形象的理解
线程阻塞需要消耗凭证(permit)，这个凭证最多只有1个。
当调用 park方法时

如果有凭证，则会直接消耗掉这个凭证然后正常退出;
如果无凭证，就必须阻塞等待凭证可用:

而unpark则相反，它会增加一个凭证，但凭证最多只能有1个，累加无效。

面试题

为什么可以突破wait/notify的原有调用顺序?
因为unpark获得了一个凭证，之后再调用park方法，就可以名正言顺的凭证消费，故不会阻塞。先发放了凭证后续可以畅通无阻。
为什么唤醒两次后阻塞两次，但最终结果还会阻塞线程?
因为凭证的数量最多为1，连续调用两次 unpark 和调用一次 unpark 效果一样，只会增加一个凭证;