Future.get卡死,线程池的一个坑点

2020-08-24  本文已影响0人  但莫

如果线程池的拒绝策略设置成DiscardPolicy或者DiscardOldestPolicy,通过Future获取执行结果,可能导致线程会一直阻塞。

问题复现

  // 创建一个单线程,拒绝策略时 DiscardPolicy
  private final static ThreadPoolExecutor executorService = new
      ThreadPoolExecutor(1, 1, 1L, TimeUnit.MINUTES,
      new SynchronousQueue<Runnable>(), new ThreadPoolExecutor.DiscardPolicy());

  public static void main(String[] args) throws Exception {
    //提交任务,阻塞 5 秒
    Future taskOne = executorService.submit(() -> {
      try {
        Thread.sleep(5000);
      } catch (InterruptedException e) {
        e.printStackTrace();
      }
    });
    //此时,队列和线程已经都被占用,当前提交的任务会执行拒绝策略
    Future taskTwo = null;
    try {
      taskTwo = executorService.submit(() -> System.out.println("start runable three"));
    } catch (Exception e) {
      System.out.println(e.getLocalizedMessage());
    }
    System.out.println("获取结果:");
    System.out.println("task one " + taskOne.get()); //(5)等待任务one执行完毕
    System.out
        .println("task two " + (taskTwo == null ? null : taskTwo.get())); // (7)等待任务three执行完毕
    executorService.shutdown(); //关闭线程池,阻塞直到所有任务执行完毕
  }

执行结果如下,第一个task正常可以获取结果,但是第二个task一直获取不到结果,程序一直卡在这里,不会继续执行。

获取结果:
task one null

问题分析

提交任务到线程池时,会包装成 FutureTask ,初始状态是 NEW。执行的任务是包装后的FutureTask对象。

public Future<?> submit(Runnable task) {
    if (task == null) throw new NullPointerException();
    // 包装成 FutureTask
    RunnableFuture<Void> ftask = newTaskFor(task, null);
    execute(ftask);
    return ftask;
}
protected <T> RunnableFuture<T> newTaskFor(Runnable runnable, T value) {
    return new FutureTask<T>(runnable, value);
}
public FutureTask(Runnable runnable, V result) {
    this.callable = Executors.callable(runnable, result);
    this.state = NEW;       // ensure visibility of callable
}

提交执行任务方法逻辑如下。

public void execute(Runnable command) {
  ...
  //如果线程个数小于核心线程数则新增处理线程
  int c = ctl.get();
  if (workerCountOf(c) < corePoolSize) {
      if (addWorker(command, true))
          return;
      c = ctl.get();
  }
  // 如果当前线程个数已经达到核心线程数则把任务放入队列
  if (isRunning(c) && workQueue.offer(command)) {
      int recheck = ctl.get();
      if (! isRunning(recheck) && remove(command))
          reject(command);
      else if (workerCountOf(recheck) == 0)
      addWorker(null, false);
  }
  // 尝试新增处理线程
  else if (! addWorker(command, false))
      reject(command); //新增失败则调用拒绝策略
}

示例代码中第二个任务会执行到reject逻辑。DiscardPolicy的方法是空实现,所以新创建的FutureTask还是NEW状态,这个状态和get方法阻塞有密切的关系。

DiscardPolicy 和 DiscardOldestPolicy 代码如下。他们有一个共同点就是没有处理task的状态。

public static class DiscardPolicy implements RejectedExecutionHandler {
    /**
     * 空方法,task会保留在NEW状态
     */
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
    }
}
public static class DiscardOldestPolicy implements RejectedExecutionHandler {
    /**
     * poll 出一个任务,但是没有任务处理,所以poll出来的任务是NEW状态
     */
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
        if (!e.isShutdown()) {
            e.getQueue().poll();
            e.execute(r);
        }
    }
}    

先看下 FutureTask 的状态。前面我们看到了初始化状态是NEW,其他状态说明如下。

private static final int NEW          = 0; 新的任务,初始状态
private static final int COMPLETING   = 1; 当任务被设置结果时,处于COMPLETING状态,这是一个中间状态。
private static final int NORMAL       = 2; 表示任务正常结束。
private static final int EXCEPTIONAL  = 3; 表示任务因异常而结束
private static final int CANCELLED    = 4; 任务还未执行之前就调用了cancel(true)方法,任务处于CANCELLED
private static final int INTERRUPTING = 5; 当任务调用cancel(true)中断程序时,任务处于INTERRUPTING状态,这是一个中间状态。
private static final int INTERRUPTED  = 6; 任务调用cancel(true)中断程序时会调用interrupt()方法中断线程运行,任务状态由INTERRUPTING转变为INTERRUPTED

继续看下 FutureTask 的get方法。

public V get() throws InterruptedException, ExecutionException {
    int s = state;
    //当状态值<=COMPLETING时需要等待,否则调用report返回
    if (s <= COMPLETING)
        s = awaitDone(false, 0L);
    return report(s);
}
private V report(int s) throws ExecutionException {
    Object x = outcome;
    // 正常结束,返回结果
    if (s == NORMAL)
        return (V)x;
    // 如果是 >= CANCELLED 抛出取消异常,包括:CANCELLED,INTERRUPTING,INTERRUPTED状态
    if (s >= CANCELLED)
        throw new CancellationException();
    // 剩下的条件就是 EXCEPTIONAL 了,执行的任务抛出异常
    throw new ExecutionException((Throwable)x)
}

到这里已经很清楚了。FutureTask状态>COMPLETING 才会返回。因为拒绝策略没有修改FutureTask的状态,FutureTask的状态一直是NEW,所以不会返回。

其他 RejectedExecutionHandler 为什么不会导致阻塞

我看看下默认的 AbortPolicy 的实现:

public static class AbortPolicy implements RejectedExecutionHandler {
    // 回忆一下submit方法,最后会执行reject策略。
    // AbortPolicy 直接抛出异常,调用方马上可以获取结果
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
        throw new RejectedExecutionException("Task " + r.toString() +
                                             " rejected from " +
                                             e.toString());
    }
}

CallerRunsPolicy 策略则是让调用线程执行提交的任务,执行任务时会更新状态,自然也不会阻塞。

public static class CallerRunsPolicy implements RejectedExecutionHandler {
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
        if (!e.isShutdown()) {
            r.run();
        }
    }
}

解决方案

  1. 使用带超时时间的get方法,这样使用DiscardPolicy拒绝策略不会一直阻塞。
  2. 如果一定要使用Discardpolicy 拒绝策略,需要自定义拒绝策略。
public void rejectedExecution(Runnable runable, ThreadPoolExecutor e) {
    if (! e.isShutdown()) {
        if(null ! = runable && runable instanceof FutureTask){
            ((FutureTask) runable).cancel(true);
          }
      }
}
上一篇下一篇

猜你喜欢

热点阅读