java - 垃圾收集和线程

Question

AFAIK 当 GC 正在做它的事情时，VM 会阻塞所有正在运行的线程——或者至少在它压缩堆时。在 CLR 和 JVM (截至 2010 年 1 月的生产版本) 的现代实现中是否是这种情况？请不要提供有关 GC 的基本链接，因为我了解基本的工作原理。

我假设全局锁定是这种情况，因为当压缩发生时，引用可能在移动期间无效，并且锁定整个堆似乎最简单(即通过阻塞所有线程间接地)。我可以想象更强大的机制，但 KISS 经常占上风。

如果我不正确，我的问题将通过对用于最大限度减少阻塞的策略的简单解释来回答。如果我的假设是正确的，请对以下两个问题提供一些见解:

1. 如果这确实是这种行为，那么像 JBOSS 和 Glassfish 这样的重量级企业引擎如何保持始终如一的高 TPS 率？我在 JBOSS 上进行了一些谷歌搜索，我期待在 APACHE 上找到一些适合 Web 处理的内存分配器。

2. 面对 NUMA 式架构(可能在不久的将来)，这听起来像是一场灾难，除非进程受线程和内存分配的 CPU 限制。

Answer 1

答案是这取决于所使用的垃圾收集算法。在某些情况下，您在 GC 期间停止所有线程是正确的。在其他情况下，您在正常线程运行时进行垃圾收集是不正确的。要了解 GC 是如何实现这一点的，您需要详细了解垃圾收集器的理论和术语，并结合对特定收集器的了解。这根本不适合简单的解释。

哦，是的，值得指出的是，许多现代收集器本身并没有压实阶段。相反，它们通过将 Activity 对象复制到新“空间”并在完成后将旧“空间”归零来工作。

If I am incorrect my question would be answered by a simple explanation of the strategy used to minimise blocking.

如果你真的想了解垃圾收集器的工作原理，我建议:

• ”Garbage Collection: Algorithms for Automatic Dynamic Memory Management" 作者:理查德·琼斯。
• "The Garbage Collection Handbook: The Art of Automatic Memory Management"经过理查德·琼斯、安东尼·霍斯金和艾略特·莫斯

...请注意，要找到生产垃圾收集器内部的准确、详细、公开的描述并不容易。 (虽然在 Hotspot GC 的情况下，您可以查看源代码...)

编辑:回应 OP 的评论 ...

"It seems it is as I thought -- there is no getting around the "stop the world" part."

这取决于。在 Java 6 Concurrent Collector 的情况下，在标记根(包括堆栈)期间有两次暂停，然后其他对象的标记/复制并行进行。对于其他类型的并发收集器，在收集器运行时使用读或写屏障来捕获收集器和应用程序线程否则会相互干扰的情况。我现在没有 [Jones] 的副本，但我还记得有可能使“停止世界”间隔可以忽略不计……代价是更昂贵的指针操作和/或不收集所有垃圾。