为什么这个线程池没有被垃圾回收？

Question

在此代码示例中，使用了 ExecutorService 并允许超出范围。

public static void main(String[] args)
{
    ExecutorService executorService = Executors.newFixedThreadPool(3);
    executorService.submit(new Runnable()
    {
        public void run()
        {
            System.out.println("hello");
        }
    });
}

一旦 executorService 超出范围，它应该被收集并最终确定。 ThreadPoolExecutor 中的finalize() 方法调用shutdown()。

/**
 * Invokes {@code shutdown} when this executor is no longer
 * referenced and it has no threads.
 */
protected void finalize() {
    shutdown();
}

一旦 shutdown() 被调用，池线程应该终止并且 JVM 应该被允许退出。然而 executorSerivce 永远不会被收集，因此 JVM 保持活动状态。甚至调用 System.gc() 似乎也不起作用。为什么即使 main() 终止后 executorService 也没有被收集？

注意：我知道我应该自己调用 shutdown() 并且我总是在测试之外调用。我很好奇为什么最终确定在这里不起作用。

Answer 1

这实际上与 GC 的不确定性没有任何关系，尽管它没有帮助！ （这是您示例中的原因之一，但即使我们“修复”它以消耗内存并强制进行集合，它仍然不会最终确定）

执行器创建的工作线程是内部类，它们具有对执行者本身。 （他们需要它才能看到队列、运行状态等！）正在运行的线程不会被垃圾收集，因此池中的每个线程都有该引用，它们将使执行器保持活动状态，直到所有线程都死掉。如果您不手动执行某些操作来停止线程，它们将永远保持运行，并且您的 JVM 将永远不会关闭。

Answer 2

阿菲是正确的；线程池的线程将防止它被垃圾收集。当你调用 Executors.newFixedThreadPool(3) 时，你会得到一个像这样构造的 ThreadPoolExecutor：

ThreadPoolExecutor(3, 3, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());

如果你阅读 ThreadPoolExecutor 的 JavaDoc，它会说：

程序中不再引用且没有剩余的池
线程将自动关闭。如果您想确保
即使用户忘记调用，未引用的池也会被回收
shutdown()，那么你必须安排未使用的线程最终死亡，
通过设置适当的保持活动时间，使用下限为零
核心线程和/或设置allowCoreThreadTimeOut(boolean)。

如果您希望线程池像您期望的那样完成，您应该执行其中一项操作。

Answer 3

如果您希望在 Executor 服务超出范围时最终确定线程，您应该像 mjt 建议的那样避免使用

    ExecutorService executorService = Executors.newFixedThreadPool(3);`

和 use 例如：

ExecutorService executorService = new ThreadPoolExecutor(0, 3, 10, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());

Answer 4

终结器太不可预测了。依赖它们通常是不好的做法。
您可以在 Joshua Bloch 的“Effective java”（第 1.7 项）

Answer 5

因为垃圾收集是“不确定的”，即您无法预测它何时发生，因此您无法准确预测 Finalize 方法何时运行。您只能使对象符合GC并建议使用System.gc()进行GC，而没有任何保证。

更糟糕的线程是由 JVM 处理的操作系统特定的并且很难预测......

Answer 6

一旦 executorService 超出范围，它应该被收集并最终确定。

事实并非如此——一旦超出范围，它就可以被收集并最终确定。 VM 规范 关于对象何时最终确定，或者甚至如果它们已最终确定：

Java 编程语言没有指定多久将调用终结器，只是说它将在重用对象的存储之前发生。