首页 > 软件编程 > java > Java线程中断机制和LockSupport

Java中的线程中断机制和LockSupport详解

2023-09-26 11:14:42 作者：苦糖果

这篇文章主要介绍了Java中的线程中断机制和LockSupport详解,在Java中没有办法立即停止一条线程,然而停止线程却显得尤为重要,如取消一个耗时操作,因此,Java提供了一种用于停止线程的协商机制中断,也即中断标识协商机制,需要的朋友可以参考下

线程中断机制

线程中断机制概念

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

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

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

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

常用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）。

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

通过一个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;
    }

通过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);
    }

通过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());
    }

在需要中断的线程中不断监听中断状态，一旦发生中断，就执行相应的中断处理业务逻辑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，这就导致无限循环了

LockSupport

LockSupport初探

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

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

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

线程等待唤醒机制

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却需要消费两个凭证，杯够，不能放行

LockSupport总结：

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

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

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

到此这篇关于Java中的线程中断机制和LockSupport详解的文章就介绍到这了,更多相关Java线程中断机制和LockSupport内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！