java - 为什么垃圾收集器在回收内存之前停止所有线程

Question

我在看一些性能相关的帖子，然后我遇到了“Java 的垃圾收集器在回收内存之前停止所有线程，这也是一个性能问题”这句话。我试图在 Google 上找到它，但找不到。

有人可以分享一些东西让我清楚吗？

Answer 1

简短但信息量不大的答案是因为很难不这样做，所以让我们详细说明一下。

HotSpot JVM 中有许多内置收集器(参见 https://blogs.oracle.com/jonthecollector/entry/our_collectors )。分代收集器已经有了显着的发展，但正如我们所说，它们仍然无法实现完全并发。它们可以并发标记哪些对象已死，哪些未死，它们可以并发清除死对象，但它们仍然无法在不停止程序的情况下并发压缩碎片化的活对象 (*)。

这主要是因为要确保您不会通过更改对象的堆位置并更新对它的所有引用来破坏某人的程序，而不是停止整个世界并一口气完成，这真的非常非常困难。也很难确保您正在移动的所有有生命的物体都不会在您的眼皮底下被改变。

分代收集器仍然可以在不停止世界和做必要工作的情况下运行很长一段时间，但他们的算法仍然在延迟不可避免的事情，不能保证完全并发的 GC。请注意在描述许多 GC 算法时如何使用像moSTLy concurrent(即不总是并发)这样的短语。

还有像 G1GC 这样的非分代收集器，它们可以显示出很棒的结果(以至于 G1GC 将成为 HotSpot 中的默认收集器)，但它们仍然不能保证不会出现 stop-the-world 暂停。这里的问题又是并发压缩，但特别是对于 G1 这不是一个问题，因为它可以同时执行一些基于区域的压缩。

如果说这是表面现象，那只是一种修饰 - 这个区域很大，我建议您查看一些有关该主题的可访问 Material ，例如 Gil Tene 的 Understanding Garbage Collection对于它背后的一些理论或 Emad Benjamin 的 Virtualizing and Tuning Large Scale JVMs一些实际问题和解决方案。

(*) 不过，这并不是一个完全无法解决的问题。 Azul 的 Zing JVM 及其 C4 垃圾收集器声称完全并发收集(有一份关于它的白皮书，但您可能会发现 details here 更有趣)。 OpenJDK 的 Shenandoah 项目也 shows very promising results .不过，正如 the8472 所解释的那样，您会在吞吐量和复杂性方面付出一些代价。 G1GC 团队考虑过采用完全并发的算法，但认为 STW 收集器的好处在 G1GC 的上下文中胜过它。