中断机制是个协商机制
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个
总结：
