在执行器服务上调度的守护进程线程;解释为什么这是不好的形式

我对在用;也就是说，调用 或 将导致池中创建的线程正常退出。如果他们响应你，可以确定最终等将被调用，你会得到一个干净的，可预测的退出（在那里你可以清理任何资源等）。ExectuorServiceshutdownshutdownNowinterrupt

但是，如果您已将线程设置为守护程序（通过执行程序），如下所示。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 将突然终止任何守护程序线程。在上面的示例中，调度然后突然终止的（守护进程）线程将绕过任何最终块，并且任何可中断的方法都不会抛出DistrutheatedException。

因此，我倾向于认为将 池中使用的线程标记为守护程序是不好的做法......我的问题实际上是帮助我说出为什么。ThreadPoolExecutor

为什么在执行器服务的线程池中使用守护程序线程是不可取的做法（或者如果你不同意的话不是）？特别是，我对描述虚拟机关闭与正常关闭（具有中断策略且运行良好的线程）与守护程序线程的生命周期感兴趣。

扩展最后一点，on 将调用自身，但是当它使用守护程序线程时，如果 VM 调用了它们，它们可能已经终止了。那么线程池的行为是什么呢？如果底层线程突然终止，它是否会被诱骗以保持活动状态（因此不会退出 VM）？finalizeThreadPoolExecutorshutdownfinalize

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