垃圾收集和线程 [英] Garbage Collection and Threads

问题描述

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

我认为全局锁定就是这种情况，因为当发生压缩时，引用在移动期间可能是无效的，看起来最简单的方法就是锁定整个堆（即间接阻止所有线程）。我可以想象更强大的机制，但KISS经常占上风。

如果我不正确，我的问题将通过简单解释用于最小化阻塞的策略来回答。如果我的假设是正确的，请提供一些有关以下两个问题的见解：

1. 如果这确实是行为，那么重量级像JBOSS和Glassfish这样的企业引擎保持了一个高TPS率？我做了一些关于JBOSS的搜索，我期待在适合于Web处理的内存分配器上找到APACHE上的东西。在面对NUMA架构（可能不久的将来）时，这听起来像是一场灾难，除非进程被线程和内存分配限制了CPU。
   

解决方案

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

哦，是的，值得指出的是，许多现代收藏家本身没有压缩阶段。相反，他们通过将活动对象复制到新的空间并在完成时将旧的空间调零。

如果我是不正确的我的问题将通过对用于最小化阻塞的策略的简单解释来回答。

如果您真的想了解垃圾收集器工作，我建议：

• 垃圾收集：自动动态内存管理算法由Richard Jones提供。
垃圾收集手册：自动内存管理的艺术 by
Richard Jones，Antony Hosking和Eliot Moss

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

编辑：回应OP评论...

看起来就像我想的那样 - 没有避开停止世界的部分。

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

AFAIK when a GC is doing its thing the VM blocks all running threads -- or at least when it is compacting the heap. Is this the case in modern implementions of the CLR and the JVM (Production versions as of January 2010) ? Please do not provide basic links on GC as I understand the rudimentary workings.

I assume global locking is the case as when compaction occurs references might be invalid during the move period, and it seems simplest just to lock the entire heap (i.e., indirectly by blocking all threads). I can imagine more robust mechanisms, but KISS often prevails.

If I am incorrect my question would be answered by a simple explanation of the strategy used to minimise blocking. If my assumption is correct please provide some insight on the following two questions:

1. If this is indeed the behaviour, how do heavyweight enterprise engines like JBOSS and Glassfish maintain a consistantly high TPS rate ? I did some googling on JBOSS and I was expecting to find something on a APACHE like memory allocator suited for web processing.

2. In the face of NUMA-esque architectures (potentially the near future) this sounds like a disaster unless the processes are CPU bound by thread and memory-allocation.

解决方案

The answer is that this depends on the garbage collection algorithms used. In some cases, you are correct that all threads are stopped during GC. In other cases, you are incorrect in that garbage collection proceeds while normal threads are running. To understand how GC's achieve that, you need a detailed understanding of the theory and terminology of garbage collectors, combined with an understanding of the specific collector. It is simply not amenable to a simple explanation.

Oh yes, and it is worth pointing out that many modern collectors don't have a compaction phase per-se. Rather they work by copying live objects to a new "space" and zeroing the old "space" when they are done.

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

If you really want to understand how garbage collectors work, I recommend:

• "Garbage Collection: Algorithms for Automatic Dynamic Memory Management" by Richard Jones.
• "The Garbage Collection Handbook: The Art of Automatic Memory Management" by Richard Jones, Antony Hosking and Eliot Moss

... and beware that finding accurate, detailed, public descriptions of the internals of production garbage collectors is not easy. (Though in the case of the Hotspot GC's, you can look at the source code ...)

EDIT: in response to the OP's comment ...

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

It depends. In the case of the Java 6 Concurrent Collector, there are two pauses during the marking of the roots (including stacks), and then marking / copying of other objects proceeds in parallel. For other kinds of concurrent collector, read or write barriers are used while the collector is running to trap situations where the collector and application threads would otherwise interfere with each other. I don't have my copy of [Jones] here right now, but I also recall that it is possible to make the "stop the world" interval negligible ... at the cost of more expensive pointer operations and/or not collecting all garbage.

这篇关于垃圾收集和线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！