LockSupport、interrupt线程中断
作者:互联网
LockSupport
是一个线程阻塞工具类,所有的方法都是静态方法,可以让线程在任意位置阻塞,当然阻塞之后肯定得有唤醒的方法。
public static void park(Object blocker); // 暂停当前线程 public static void parkNanos(Object blocker, long nanos); // 暂停当前线程,不过有超时时间的限制 public static void parkUntil(Object blocker, long deadline); // 暂停当前线程,直到某个时间 public static void park(); // 无期限暂停当前线程 public static void parkNanos(long nanos); // 暂停当前线程,不过有超时时间的限制 public static void parkUntil(long deadline); // 暂停当前线程,直到某个时间 public static void unpark(Thread thread); // 恢复当前线程 public static Object getBlocker(Thread t);
jdk文档解释:
- park
为了线程调度,禁用当前线程,除非许可可用。
如果许可可用,则使用该许可,并且该调用立即返回;否则,为线程调度禁用当前线程,并在发生以下三种情况之一以前,使其处于休眠状态
1、其他某个线程将当前线程作为目标调用unpark;
2、其他某个线程中断当前线程;
3、该调用不符合逻辑;
此方法并不报告哪个线程导致该方法返回。调用者应该重新检查最先导致线程暂停的条件。调用者还可以确定线程返回时的中断状态。
-unpark
public static void unpark(Thread thread){}
如果给定线程的许可尚不可用,则使其可用。如果线程在park上受阻塞,则它将解除其阻塞状态。否则,保证下一次调用park不会受到阻塞。如果给定线程尚未启动,则无法保证此操作有任何效果。
所以,park之后当前线程进入阻塞状态,unpark或者中断可以唤醒。park和unpark没有先后顺序之分。unpark会让线程获得许可,但最多为1。
Thread.interrupt()为什么可以有unpark()的效果呢? interrupt 实际上会调用 interrupt0, interrpt0是一个native方法,会调用thread.cpp,thread.cpp会调用 os_linux.cpp,里面代码思路大致就是 获取到操作系统中对应java的线程,然后设置标志位,再设置内存屏障,再去unpark线程,为什么会去unpark线程呢?因为如果是park状态,你连cpu时间片都分不到,谈何执行/通知?
- LockSupport.park()会检查线程是否设置了中断标志位,如果设置了,则返回(这里并不会清除中断标志位)。线程被中断后,park不会阻塞。
public class LockSupportDemo { public static Object u = new Object(); static ChangeObjectThread t1 = new ChangeObjectThread("t1"); static ChangeObjectThread t2 = new ChangeObjectThread("t2"); public static class ChangeObjectThread extends Thread { public ChangeObjectThread(String name) { super(name); } @Override public void run() { synchronized (u) { System.out.println("in " + getName()); LockSupport.park(); if (Thread.currentThread().isInterrupted()) { System.out.println("被中断了"); } System.out.println("继续执行"); } } } public static void main(String[] args) throws InterruptedException { t1.start(); Thread.sleep(1000L); t2.start(); Thread.sleep(3000L); t1.interrupt(); LockSupport.unpark(t2); t1.join(); t2.join(); } }
结果:
in t1
被中断了
继续执行
in t2
继续执行
中断
如果一个线程处于了阻塞状态(如线程调用了thread.sleep、thread.join、thread.wait、1.5中的condition.await、以及可中断的通道上的 I/O 操作方法后可进入阻塞状态),则在线程在检查中断标示时如果发现中断标示为true,则会在这些阻塞方法(sleep、join、wait、1.5中的condition.await及可中断的通道上的 I/O 操作方法)调用处抛出InterruptedException异常,并且在抛出异常后立即将线程的中断标示位清除,即重新设置为false。抛出异常是为了线程从阻塞状态醒过来,并在结束线程前让程序员有足够的时间来处理中断请求。
注,synchronized在获锁的过程中是不能被中断的,意思是说如果产生了死锁,则不可能被中断(请参考后面的测试例子)。与synchronized功能相似的reentrantLock.lock()方法也是一样,它也不可中断的,即如果发生死锁,那么reentrantLock.lock()方法无法终止,如果调用时被阻塞,则它一直阻塞到它获取到锁为止。但是如果调用带超时的tryLock方法reentrantLock.tryLock(long timeout, TimeUnit unit),那么如果线程在等待时被中断,将抛出一个InterruptedException异常,这是一个非常有用的特性,因为它允许程序打破死锁。你也可以调用reentrantLock.lockInterruptibly()方法,它就相当于一个超时设为无限的tryLock方法。
一、没有任何语言方面的需求一个被中断的线程应该终止。中断一个线程只是为了引起该线程的注意,被中断线程可以决定如何应对中断。
二、对于处于sleep,join等操作的线程,如果被调用interrupt()后,会抛出InterruptedException,然后线程的中断标志位会由true重置为false,因为线程为了处理异常已经重新处于就绪状态。
三、不可中断的操作,包括进入synchronized段以及Lock.lock(),inputSteam.read()等,调用interrupt()对于这几个问题无效,因为它们都不抛出中断异常。如果拿不到资源,它们会无限期阻塞下去。
对于Lock.lock(),可以改用Lock.lockInterruptibly(),可被中断的加锁操作,它可以抛出中断异常。等同于等待时间无限长的Lock.tryLock(long time, TimeUnit unit)。
对于inputStream等资源,有些(实现了interruptibleChannel接口)可以通过close()方法将资源关闭,对应的阻塞也会被放开。
首先,看看Thread类里的几个方法:
public static boolean interrupted | 测试当前线程是否已经中断。线程的中断状态 由该方法清除。换句话说,如果连续两次调用该方法,则第二次调用将返回 false。 |
public boolean isInterrupted() |
测试线程是否已经中断。线程的中断状态 不受该方法的影响。 |
public void interrupt() |
中断线程。 |
上面列出了与中断有关的几个方法及其行为,可以看到interrupt是中断线程。如果不了解Java的中断机制,这样的一种解释极容易造成误解,认为调用了线程的interrupt方法就一定会中断线程。
其实,Java的中断是一种协作机制。也就是说调用线程对象的interrupt方法并不一定就中断了正在运行的线程,它只是要求线程自己在合适的时机中断自己。每个线程都有一个boolean的中断状态(这个状态不在Thread的属性上),interrupt方法仅仅只是将该状态置为true。
比如对正常运行的线程调用interrupt()并不能终止他,只是改变了interrupt标示符。
一般说来,如果一个方法声明抛出InterruptedException,表示该方法是可中断的,比如wait,sleep,join,也就是说可中断方法会对interrupt调用做出响应(例如sleep响应interrupt的操作包括清除中断状态,抛出InterruptedException),异常都是由可中断方法自己抛出来的,并不是直接由interrupt方法直接引起的。
Object.wait, Thread.sleep方法,会不断的轮询监听 interrupted 标志位,发现其设置为true后,会停止阻塞并抛出 InterruptedException异常。
标签:调用,中断,LockSupport,static,interrupt,线程,public 来源: https://www.cnblogs.com/chenfx/p/15070114.html