线程中断机制和LockSupport

1. 线程中断机制

1.1 线程中断机制概念

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

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

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

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

2.2 常用API

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

public static boolean interrupted()
静态方法，Thread.interrupted();判断线程是否被中断并清除当前中断状态。这个方法做了两件事:
返回当前线程的中断状态，测试当前线程是否已被中断
将当前线程的中断状态清零并重新设为false，清除线程的中断状态
此方法有点不好理解，如果连续两次调用此方法，则第二次调用将返回false，因为连续调用两次的结果可能不一样

中断标识被清空，如果该方法被连续调用两次，第二次调用将返回false
除非当前线程在第一次和第二次调用该方法之间再次被interrupt

public boolean isInterrupted()
实例方法，判断当前线程是否被中断（通过检查中断标志位)

interrupted()与isInterrupted()的区别
方法的注释也清晰的表达了“中断状态将会根据传入的ClearInterrupted参数值确定是否重置“
所以，静态方法interrupted将会清除中断状态（传入的参数ClearInterrupted为true) ,
实例方法isInterrupted则不会（传入的参数ClearInterrupted为false）。

2.3 如何停止中断运行中的线程?

通过一个volatile变量实现

private static volatile boolean isStop = false;
 public static void main(String[] args) {
        new Thread(() -> {
            while (true) {
                if (isStop) {
                    System.out.println(Thread.currentThread().getName() + "线程isStop = true,自己退出");
                    break;
                }
                System.out.println("-------hello interrupt--------");
            }
        }, "t1").start();
        try {
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        isStop = true;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

通过AtomicBoolean

private static final AtomicBoolean atomicBoolean = new AtomicBoolean(true);

    public static void main(String[] args) {
        new Thread(() -> {
            while (atomicBoolean.get()) {
                try {
                    TimeUnit.MILLISECONDS.sleep(200);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("-------hello------");
            }
        }).start();
        try {
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        atomicBoolean.set(false);
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

通过Thread类自带的中断api实例方法实现

public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            while (true) {
                if (Thread.currentThread().isInterrupted()) {
                    System.out.println("-----t1 线程被中断了，程序结束");
                    break;
                }
                System.out.println("-----hello-------");
            }
        }, "t1");
        t1.start();
        System.out.println("t1是否被中断：" + t1.isInterrupted());
        try {
            TimeUnit.MILLISECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        t1.interrupt();
        System.out.println("t1是否被中断：" + t1.isInterrupted());
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

在需要中断的线程中不断监听中断状态，一旦发生中断，就执行相应的中断处理业务逻辑stop线程

具体来说，当对一个线程，调用interrupt()时:
①如果线程处于正常活动状态，那么会将该线程的中断标志设置为 true，仅此而已。被设置中断标志的线程将继续正常运行，不受影响。所以，interrupt()并不能真正的中断线程，需要被调用的线程自己进行配合才行。

②如果线程处于被阻塞状态（例如处于sleep, wait, join等状态)，在别的线程中调用当前线程对象的interrupt方法,那么线程将立即退出被阻塞状态，并抛出一个InterruptedException异常。在catch块中应该加上一行代码：Thread.currentThread().interrupt();
为什么要写这个？
这是维持状态。sleep()，wait()方法抛出InterruptException异常后会清除中断标志，即把中断标志设为false。而你又捕获了InterruptException，这时你基本上阻止任何更高级别的方法/线程组注意到中断。这可能会导致问题。通过调用Thread.currentThread().interrupt()，你可以设置线程的中断标志（即把中断标志设为true），因此更高级别的中断处理程序会注意到它并且可以正确处理它。

当前线程的中断标识为true，是不是线程就立刻停止?
实例方法interrupt()仅仅是设置线程的中断状态位为true，不会停止线程。中断只是一种协商机制，修改中断标识位仅此而已，不是立刻stop打断

sleep方法抛出InterruptedException后，中断标识也被清空置为false，我们在catch没有通过调用th.interrupt()方法再次将中断标识置为true，这就导致无限循环了

2. LockSupport

2.1 LockSupport初探

LockSupport是用来创建锁和其他同步类的基本线程阻塞原语。

LockSupport中的park()和 unpark()的作用分别是阻塞线程和解除阻塞线程

LockSupport类中的park等待和unpark唤醒
LockSupport类使用了一种名为Pemit(许可）的概念来做到阻塞和唤醒线程的功能，每个线程都有一个许可(permit)，
但与Semaphore不同的是，许可的累加上限是1。
permit许可证默认没有不能放行，所以一开始调park()方法当前线程就会阻塞，直到别的线程给当前线程的发放permit，park方法才会被唤醒。
调用unpark(thread)方法后，就会将thread线程的许可证permit发放，会自动唤醒park线程，即之前阻塞中的LockSuppot.pak()方法会立即返回。

2.2 线程等待唤醒机制

3种让线程等待和唤醒的方法
方式1:使用object中的wait()方法让线程等待，使用Object中的notify()方法唤醒线程
方式2:使用Juc包中Condition的await()方法让线程等待，使用signal()方法唤醒线程
方式3:LockSupport类可以阻塞当前线程以及唤醒指定被阻塞的线程

上述两个对象object和Condition使用的限制条件
线程先要获得并持有锁，必须在锁块(synchronized或lock)中
必须要先等待后唤醒，线程才能够被唤醒

LockSupport优势
正常+无锁块要求
之前错误的先唤醒后等待，LockSupport照样支持

为什么可以突破wait/notify的原有调用顺序?
因为unpark获得了一个凭证，之后再调用park方法，就可以名正言顺的凭证消费，故不会阻塞。先发放了凭证后续可以畅通无阻。

为什么唤醒两次后阻塞两次，但最终结果还会阻塞线程?
因为凭证的数量最多为1，连续调用两次unpark和调用一次 unpark效果一样，只会增加一个凭证;而调用两次park却需要消费两个凭证，杯够，不能放行

2.3 LockSupport总结：

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

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

线程阻塞需要消耗凭证(permit)，这个凭证最多只有1个。当调用park方法时如果有凭证，则会直接消耗掉这个凭证然后正常退出;如果无凭证，就必须阻塞等待凭证可用;而unpark则相反，它会增加一个凭证，但凭证最多只能有1个，累加无效。

注：本文是学习B站周阳老师《尚硅谷2022版JUC并发编程》课程所做学习笔记。