LockSupport与线程中断机制

中断机制是个协商机制

Interrupt():

将中断状态设置为true

Interrupted():（静态方法）

1.返回当前线程的中断状态

2.将中断状态清零并设置为false

is Interrupted():

判断当前线程是否被中断

如何停止中断运行中的线程？

一个线程不应该由其他线程来停止

案例：

方法1、2用 volatile或AtomicBoolean

t2对t1发起协商中断

源码分析

Interrupt():

底层是调用interrupt0():

发现interrupt0是native方法，调用的是底层操作系统或是第三方的函数库

就是把当前的中断标志位从false设置为true，并不是立刻停止当前线程。

如果某个线程正在调用阻塞方法，此时调用interrupt()会清除中断状态，立即退出阻塞状态并抛出中断异常。

isInterrupted():

被中断返回true，否则返回false

底层还是调的native方法

小结：

当前中断标志位设置为true是否就立即停止？

不会，仅仅将标志位设置为true。

案例

结果：

首先t1的默认标志位是false

此时发生打断，标志位置为true

线程并没有停止，而是运行完了，而且中断标志还是true

这时再让它休息2秒，打印发现中断标志位变成了false。

因为此时t1已经拜拜了👋🏻，中断不活动的线程不会有任何影响。

==================================================

案例2

如果在sleep还没结束前，被interrupt，此时则会抛出中断异常，并陷入死循环

解决方案：

重新将标志位设置为true

异常复现

1.中断标志位默认为false

2.线程t2将t1标志位设置为true，此时中断标志位为true

3.碰上正在执行的sleep函数，抛出中断异常并把中断状态置为false，结束阻塞状态，导致了无限循环

4.所以需要再catch中重新将中断标志位设置为true。

interrupted（）：

案例

源码分析：

底层还是调用的是isInterrupted

静态方法：这里将调用isInterrupted，参数是true,意思是需要清理中断标志位

实例方法：这里将调用isInterrupted，参数是false，不需要清理状态标志位

两个底层都是调的native方法，参数是：是否需要清除状态标志位

===========================================

LockSupprot

wait()和notify()：

正常情况：

异常情况1：

wait和notify必须在Synchronized同步代码块中执行，否则会抛异常

异常情况2：

先调用notify()再调用wait()，顺序错误

程序无法唤醒

Condition的await()和signal()

正常情况：

异常情况1：

这两个方法必须放在锁块里才能正常使用：lock和unlock

异常情况2：

调用顺序错误，先调用signal()再调用await()

同样，程序无法被唤醒

LockSupport类的park()和unpark()

park():

UNSAFE类的park方法

默认不放行，0表示永久等待

所以一开始调用park方法就会被阻塞，直到发放了通行证。

底层调用的是操作系统或是第三方函数库

unpark():

能够创建锁和阻塞原语

使用案例：

异常情况1：

不会发生异常

就算先发出通知，照样能唤醒t1。先发通行证没问题

通行证不会累计，最多只能发1个

总结：