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线程池中的前端用户而言,还是会存在极其少量的服务器繁忙:)

posted @ 2016-02-22 17:56  马宇申  阅读(...)  评论(...编辑  收藏