java - 在 ExecutorService 上调度的守护线程；解释为什么这是不好的形式

Question

我对在使用 ExectuorService 调度的线程上有序关闭的想法感到满意；也就是说，调用 shutdown 或 shutdownNow 会导致池上创建的线程优雅退出。如果他们响应 interrupt 你可以确定 finally etc 将被调用并且你会得到一个干净的、可预测的退出(你可以清理任何资源等)。

但是，如果您已将线程设置为守护进程(通过执行程序的 ThreadFactory)，如下所示。

ExecutorService pool = Executors.newSingleThreadExecutor(new ThreadFactory() {
   @Override
   public Thread newThread(Runnable runnable) {
      Thread thread = Executors.defaultThreadFactory().newThread(runnable);
      thread.setDaemon(true);
      return thread;
   }
});

在主线程终止后，VM 将突然终止所有守护线程。 在上面的例子中，一个被调度然后突然终止的(守护进程)线程将绕过任何 finally block 并且任何可中断的方法都不会抛出 InterruptedException。

所以，我倾向于认为将 ThreadPoolExecutor 的池中使用的线程标记为守护进程是不好的做法......我的问题实际上是关于帮助我表达为什么.

为什么在 ExecutorService 的线程池中使用守护线程是不好的做法(或者如果你不同意的话)？特别是我有兴趣通过优雅关闭(具有中断策略并且运行良好的线程)与守护线程来描述 VM 关闭的生命周期。

扩展最后一点，ThreadPoolExecutor 上的 finalize 将调用自身的 shutdown，但是当它使用守护线程时，它们可能已经终止如果虚拟机调用了 finalize。那么线程池的行为是什么？如果底层线程突然终止，它是否可以被欺骗以保持 Activity 状态(因此不退出 VM)？

我问的部分原因是因为我已经看到它用来绕过关闭实际 ExectorService 的需要。您能想到绕过 its 关闭生命周期会产生不良影响的场景吗？到目前为止，我能想到使用守护进程的唯一原因是走捷径，我想了解它可能导致的任何意外的副作用。

Answer 1

is it bad practice to use daemon threads in a ExecutorService's thread pool?

如果发送到特定 ExecutorService 的任务可以被突然终止，那为什么不呢，这就是守护线程所做的。但一般来说，没有多少任务可以在没有关闭仪式的情况下终止，所以如果你选择守护线程，你必须知道你在做什么。

finalize() 在对象即将被垃圾回收时调用。无法保证任何特定对象何时会被 GCd，而 ThreadPoolExecutor 也不异常(exception)，因此它的 finalize() 可能会或可能不会被调用。行为取决于特定的 JRE 实现，即使使用相同的实现，也可能会不时发生变化。