Java Thread.interrupt interrupted

Java Thread.interrupt

@(Base)[JDK, 线程, interrupt]

原文地址,转载请注明

下面这个场景你可能很熟悉，我们调用Thread.sleep(),condition.await(),但是IDE提示我们有未捕获的InterruptedException。什么是InterruptedException呢？我们又应该怎么处理呢？

大部分人的回答是，吞掉这个异常就好啦。但是其实，这个异常往往带有重要的信息，可以让我们具备关闭应用时执行当前代码回收的能力。

Blocking Method

如果一个方法抛出InterruptedException(或者类似的)，那么说明这个方法是一个阻塞方法。（非阻塞的方法需要你自己判断，阻塞方法只有通过异常才能反馈出这个东西）

当我们直接调用一个Unschedule的线程的interrupt方法的时候，会立即使得其变成schedule(这一点非常重要，由JVM保证), 并且interrupted状态位为true。

通常low-level method，像sleep和await这些方法就会在方法内部处理这个标志位。例如await就会在醒来之后检查是否有中断。所以在Sync内部通常在唤醒之后都会检查中断标志位。

看下面一段代码：

  public static void main(String[] args) {
        Thread a = new Thread(new Runnable() {
            @Override
            public void run() {
                long start = System.currentTimeMillis();
                try {
                    Thread.sleep(10000);
                } catch (InterruptedException e) {
                    // what to do ?
                }
                System.out.println(System.currentTimeMillis() - start);
            }
        });
        a.start();
        // 加上这句话，执行时间是0，没有这句话执行时间是10，你感受下
        a.interrupt(); 
}

所以，当我们直接Interrupt一个线程的时候，他会立即变成可调度的状态，也就是会里面从阻塞函数中返回。这个时候我们拿到InterruptedException（或者在更底层看来只是一个线程中断标志位）的时候应该怎么做呢？

在low-level的层面来说，只有中断标志位，这一个概念，并没有interruptException，只是jdk的框架代码中，为了强制让客户端处理这种异常，所以在同步器、线程等阻塞方法中唤醒后自动检测了中断标志位，如果符合条件，则直接抛出受检异常。

How to Deal

Propagating InterruptedException to callers by not catching it

当你的方法调用一个blocking方法的时候，说明你这个方法也是一个blocking方法（大多数情况下）。这个时候你就需要对interruptException有一定的处理策略，通常情况下最简单的策略是把他抛出去。参考下面的代码：

参考blockingQueue的写法，底层使用condition对象，当await唤醒的时候有interruptException的时候，直接抛出，便于上层处理。换句话说，你的代码这个层面没有处理的必要和意义。

public class TaskQueue {
    private static final int MAX_TASKS = 1000;

    private BlockingQueue<Task> queue 
        = new LinkedBlockingQueue<Task>(MAX_TASKS);

    public void putTask(Task r) throws InterruptedException { 
        queue.put(r);
    }

    public Task getTask() throws InterruptedException { 
        return queue.take();
    }
}

Do some clean up before thrown out

有时候，在当前的代码层级上，抛出interruptException需要清理当前的类，清理完成后再把异常抛出去。下面的代码，表现的就是一个游戏匹配器的功能，首先等待玩家1，玩家2都到达之后开始游戏。如果当前玩家1到达了，线程接受到interrupt请求，那么释放玩家1，这样就不会有玩家丢失。

public class PlayerMatcher {
    private PlayerSource players;

    public PlayerMatcher(PlayerSource players) { 
        this.players = players; 
    }

    public void matchPlayers() throws InterruptedException { 
        Player playerOne, playerTwo;
         try {
             while (true) {
                 playerOne = playerTwo = null;
                 // Wait for two players to arrive and start a new game
                 playerOne = players.waitForPlayer(); // could throw IE
                 playerTwo = players.waitForPlayer(); // could throw IE
                 startNewGame(playerOne, playerTwo);
             }
         }
         catch (InterruptedException e) {  
             // If we got one player and were interrupted, put that player back
             if (playerOne != null)
                 players.addFirst(playerOne);
             // Then propagate the exception
             throw e;
         }
    }
}

Resorting Status

如果已经到了抛不出去的地步了，比如在Runnable中。当一个blocking-method抛出一个interruptException的时候，当前线程的中断标志位实际是已经被清除了的，如果我们这个时候不能再次抛出interruptException，我们就无法向上层表达中断的意义。这个时候只有重置中断状态。但是，这里面还是有很多技巧...不要瞎搞：

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

注意上面代码，catch异常的位置，在看下面一段代码

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

这段代码就会造成无限循环，catch住之后，设置中断标志，然后loop，take()函数立即抛出InterruptException。你感受下。

千万不要直接吞掉

当你不能抛出InterruptedException，不论你决定是否响应interrupt request，这个时候你都必须重置当前线程的interrupt标志位，因为interrupt标志位不是给你一个人看的，还有很多逻辑相应这个状态。标准的线程池（ThreadPoolExecutor）的Worker对象（内部类）其实也会对interrupt标识位响应，所以向一个task发出中断信号又两个作用，1是取消这个任务，2是告诉执行的Thread线程池正在关闭。如果一个task吞掉了中断请求，worker thread就不能响应中断请求，这可能导致application一直不能shutdown.

万不要直接吞掉
// Don't do this 
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 swallowed) { 
             /* DON'T DO THIS - RESTORE THE INTERRUPTED STATUS INSTEAD */
         }
    }
}

Implementing cancelable tasks

从来没有任何文档给出interruption明确的语义，但是其实在大型程序中，中断可能只有一个语义：取消，因为别的语义实在是难以维持。举个例子，一个用户可以用通过GUI程序，或者通过一些网络机制例如JMX或者WebService来发出一个关闭请求。也可能是一段程序逻辑，再举个简单的例子，一个爬虫程序如果检测到磁盘满了，可能就会自行发出中断（取消）请求。或者一个并行算法可能会打开多个线程来搜索什么东西，当某个框架搜索到结果之后，就会发出中断（取消）请求。

一个task is cancelable并不意味着他必须立刻响应中断请求。如果一个task在loop中执行，一个典型的写法是在每次Loop中都检查中断标志位。可能循环时间会对响应时间造成一定的delay。你可以通过一些写法来提高中断的响应速度，例如blocking method里面往往第一行都是检查中断标志位。

Interrupts can be swallowed if you know the thread is about to exit 唯一可以吞掉interruptException的场景是，你明确知道线程就要退出了。这个场景往往出现在，调用中断方法是在你的类的内部，例如下面一段代码，而不是被某种框架中断。

public class PrimeProducer extends Thread {
    private final BlockingQueue<BigInteger> queue;
    PrimeProducer(BlockingQueue<BigInteger> queue) {
        this.queue = queue;
    }
    public void run() {
        try {
            BigInteger p = BigInteger.ONE;
            while (!Thread.currentThread().isInterrupted())
                queue.put(p = p.nextProbablePrime());
        } catch (InterruptedException consumed) {
            /* Allow thread to exit */
        }
    }
    public void cancel() { interrupt(); }
}

Non-Interruptible Blocking

并不是所有blockingMethod都支持中断。例如input/outputStream这两个类，他们就不会抛出InterruptedException，也不会因为中断而直接返回。在Socket I/O而言，如果线程A关闭了Socket，那么正在socket上读写数据的B、C、D都会抛出SocketException. 非阻塞I/O（java.nio）也不支持interruptiable I/O，但是blocking operation可以通过关闭channel或者调用selector.wakeUp方法来操作。类似的是，内部锁（Synchronized Block）也不能被中断，但是ReentrantLock是支持可被中断模式的。

Non-Cancelable Tasks

有一些task设计出来就是不接受中断请求，但是即便如此，这些task也需要restore中断状态，以便higher-level的程序能够在这个task执行完毕后响应中断请求。

下面这段代码就是一个BlockingQueue.poll()忽略中断的的例子（和上面我的备注一样，不要在catch里面直接restore状态，不然queue.take()会造成无限循环。

public Task getNextTask(BlockingQueue<Task> queue) {
    boolean interrupted = false;
    try {
        while (true) {
            try {
                return queue.take();
            } catch (InterruptedException e) {
                interrupted = true;
                // fall through and retry
            }
        }
    } finally {
        if (interrupted)
            Thread.currentThread().interrupt();
    }
}

Summary

你可以利用interruption mechanism来提供一个灵活的取消策略。任务可以自行决定他们是否可以取消，或者如何响应中断请求，或者处理一些task relative cleanup。即便你想要忽略中断请求，你也需要restore中断状态，当你catchInterruptedException的时候，当higher不认识他的时候，就不要抛出啦。

如果你的代码在框架（包括JDK框架）中运行，那么interruptException你就务必像上面一样处理。如果单纯的你自己的小代码片段，那么你可以简单地认为InterruptException就是个bug。

在生产环境下，tomcat shutdown的时候，也会大量关闭线程池，发出中断请求。这个时候如果响应时间过于慢就会导致tomcat shutdown非常的慢（甚至于不响应）。所以大部分公司的重启脚本中都含有重启超时（例如20s）的一个强杀(kill -9)的兜底策略，这个过程对于程序来说就等于物理上的断电，凡是不可重试，没有断电保护，业务不幂等的情况都会产生大量的数据错误。

就现在业内的做法而言，大部分上述描述的问题几乎已经不再通过interrupt这种关闭策略来解决（因为实在难以解决），转而通过整体的系统架构模型来规避数据问题，例如数据库事务，例如可重试的幂等任务等等。

针对前端用户而言，就是ng的上下线心跳切换。但即使如此，对于请求已经进入tomcat线程池中的前端用户而言，还是会存在极其少量的服务器繁忙：）