不学无数——InterruptedException异常

InterruptedException异常

在了解InterruptedException异常以前应该了解如下的几个关于线程的一些基础知识。

线程的状态

线程在必定的条件下会发生状态的改变，下面是线程的一些状态

• 初始(NEW)：新建一个线程的对象，还未调用start方法
• 运行(RUNNABLE)：java线程中将已经准备就绪(Ready)和正在运行中(Running)的两种状态都统称为“Runnable”。准备就绪的线程会被放在线程池中等待被调用
• 阻塞(BLOCKED)：是由于某种的缘由而放弃了CPU的使用权，暂时的中止了运行。直到线程进入准备就绪(Ready)状态才会有机会转到运行状态
• 等待(WAITING)：该状态的线程须要等待其余线程作出一些特定的动做（通知或者是中断）
• 超时等待(TIME_WAITING)：该状态和上面的等待不一样，他能够在指定的时间内自行返回
• 终止(TERMINATED)：线程任务执行完毕

而InterruptedException异常从字面意思上就是中断异常，那么什么是中断呢？学习中断以前咱们先了解一下具体什么是阻塞

线程阻塞

线程阻塞一般是指一个线程在执行过程当中暂停，以等待某个条件的触发。而什么状况才会使得线程进入阻塞的状态呢？

• 等待阻塞：运行的线程执行wait()方法，该线程会释放占用的全部资源，JVM会把该线程放入“等待池”中。进入这个状态后，是不能自动唤醒的，必须依靠其余线程调用notify()或notifyAll()方法才能被唤醒
• 同步阻塞：运行的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则JVM会把该线程放入“锁池”中
• 其余阻塞：运行的线程执行sleep()或join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程从新转入就绪状态

线程中断

若是咱们有一个运行中的软件，例如是杀毒软件正在全盘查杀病毒，此时咱们不想让他杀毒，这时候点击取消，那么就是正在中断一个运行的线程。

每个线程都有一个boolean类型的标志，此标志意思是当前的请求是否请求中断，默认为false。当一个线程A调用了线程B的interrupt方法时，那么线程B的是否请求的中断标志变为true。而线程B能够调用方法检测到此标志的变化。

1. 阻塞方法：若是线程B调用了阻塞方法，若是是否请求中断标志变为了true，那么它会抛出InterruptedException异常。抛出异常的同时它会将线程B的是否请求中断标志置为false
2. 非阻塞方法：能够经过线程B的isInterrupted方法进行检测是否请求中断标志为true仍是false，另外还有一个静态的方法interrupted方法也能够检测标志。可是静态方法它检测完之后会自动的将是否请求中断标志位置为false。例如线程A调用了线程B的interrupt的方法，那么若是此时线程B中用静态interrupted方法进行检测标志位的变化的话，那么第一次为true，第二次就为false。下面为具体的例子：

/**
 * @program: Test
 * @description:
 * @author: hu_pf@suixingpay.com
 * @create: 2018-07-31 15:43
 **/
public class InterrupTest implements Runnable{

    public void run(){
            try {
                while (true) {
                    Boolean a = Thread.currentThread().isInterrupted();
                    System.out.println("in run() - about to sleep for 20 seconds-------" + a);
                    Thread.sleep(20000);
                    System.out.println("in run() - woke up");
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();//若是不加上这一句，那么cd将会都是false，由于在捕捉到InterruptedException异常的时候就会自动的中断标志置为了false
                Boolean c=Thread.interrupted();
                Boolean d=Thread.interrupted();
                System.out.println("c="+c);
                System.out.println("d="+d);
            }
    }
    public static void main(String[] args) {
        InterrupTest si = new InterrupTest();
        Thread t = new Thread(si);
        t.start();
        //主线程休眠2秒，从而确保刚才启动的线程有机会执行一段时间
        try {
            Thread.sleep(2000);
        }catch(InterruptedException e){
            e.printStackTrace();
        }
        System.out.println("in main() - interrupting other thread");
        //中断线程t
        t.interrupt();
        System.out.println("in main() - leaving");
    }
}

复制代码

打印的参数以下：

in run() - about to sleep for 20 seconds-------false
in main() - interrupting other thread
in main() - leaving
c=true
d=false

复制代码

如今知道线程能够检测到自身的标志位的变化，可是他只是一个标志，若是线程自己不处理的话，那么程序仍是会执行下去，就比如，老师在学校叮嘱要好好学习，具体何时，如何好好学习仍是看自身。

所以interrupt() 方法并不能当即中断线程，该方法仅仅告诉线程外部已经有中断请求，至因而否中断还取决于线程本身

InterruptedException异常的处理

简单的了解了什么是阻塞和中断之后，咱们就该了解碰到InterruptedException异常该如何处理了。

不要无论不顾

有时候阻塞的方法抛出InterruptedException异常并不合适，例如在Runnable中调用了可中断的方法，由于你的程序是实现了Runnable接口，而后在重写Runnable接口的run方法的时候，那么子类抛出的异常要小于等于父类的异常。而在Runnable中run方法是没有抛异常的。因此此时是不能抛出InterruptedException异常。若是此时你只是记录日志的话，那么就是一个不负责任的作法，由于在捕获InterruptedException异常的时候自动的将是否请求中断标志置为了false。至少在捕获了InterruptedException异常以后，若是你什么也不想作，那么就将标志从新置为true，以便栈中更高层的代码能知道中断，而且对中断做出响应。

捕获到InterruptedException异常后恢复中断状态

public class TaskRunner implements Runnable {
    private BlockingQueue<Task> queue;
 
    public TaskRunner(BlockingQueue<Task> queue) { 
        this.queue = queue; 
    }
 
    public void run() { 
        try {
             while (true) {
                 Task task = queue.take(10, TimeUnit.SECONDS);
                 task.execute();
             }
         }
         catch (InterruptedException e) { 
             // Restore the interrupted status
             Thread.currentThread().interrupt();
         }
    }
}

复制代码

参考文章

• blog.csdn.net/sinat_34596…

• blog.csdn.net/u011784767/…

• www.ibm.com/developerwo…

• blog.csdn.net/pange1991/a…