为什么JVM一旦引用计数达到0就会销毁资源？ [英] Why doesn't the JVM destroy a resource as soon as its reference count hits 0?

问题描述

  if（obj）
 
我一直很想知道为什么Java中的垃圾收集器会激活它， .refCount == 0）
 {
 delete obj; 
} 
  

Java是如何被我忽略的呢？ p>

谢谢

解决方案

每个JVM都不同，但HotSpot JVM不主要依靠引用计数作为垃圾收集的手段。引用计数具有易于实现的优点，但它本质上易于出错。特别是，如果您有一个参考周期（一组对象在一个周期内都相互引用），那么引用计数将无法正确回收这些对象，因为它们都具有非零引用计数。这迫使你不时使用辅助垃圾回收器，这往往会变慢（Mozilla Firefox有这个确切的问题，他们的解决方案是以代码可读性为代价添加到垃圾回收器中）。例如，这就是为什么像C ++这样的语言倾向于使用引用计数和 weak_ptr 的 shared_ptr s

此外，将引用计数与每个对象关联会导致分配引用的成本大于正常，因为涉及额外的簿记调整引用计数（在多线程中只会变得更糟）。此外，使用引用计数排除了某些类型的快速内存分配器的使用，这可能是一个问题。它也倾向于导致其天真形式的堆碎片化，因为物体是通过记忆分散的，而不是紧密堆积的，减少分配时间并导致局部性差。

HotSpot JVM使用各种不同的技术来进行垃圾收集，但其主垃圾收集器被称为停止 - 复制收集器。该收集器通过在内存中相邻分配对象来工作，并允许极快（一个或两个汇编指令）分配新对象。当空间耗尽时，所有新对象都会同时被GC化，这通常会杀死大部分构建的新对象。因此，GC比通常的引用计数实现要快得多，并且最终具有更好的局部性和更好的性能。

为了比较垃圾收集，以及快速浏览HotSpot中GC的工作原理，您可能需要查看 这些演讲幻灯片 来自我去年夏天编写的编译器课程。您也可以查看 HotSpot垃圾回收白皮书 ，它详细介绍了垃圾收集器的工作原理，包括按应用程序调整收集器的方式。

希望这帮助！

I have always wondered why the garbage collector in Java activates whenever it feels like it rather than do:

if(obj.refCount == 0)
{
   delete  obj;
}

Are there any big advantages to how Java does it that I overlooked?

Thanks

解决方案

Each JVM is different, but the HotSpot JVM does not primarily rely on reference counting as a means for garbage collection. Reference counting has the advantage of being simple to implement, but it is inherently error-prone. In particular, if you have a reference cycle (a set of objects that all refer to one another in a cycle), then reference counting will not correctly reclaim those objects because they all have nonzero reference count. This forces you to use an auxiliary garbage collector from time to time, which tends to be slower (Mozilla Firefox had this exact problem, and their solution was to add in a garbage collector at the cost of much code readability). This is why, for example, languages like C++ tend to have a combination of shared_ptrs that use reference counting and weak_ptrs that don't use reference cycles.

Additionally, associating a reference count with each object makes the cost of assigning a reference greater than normal, because of the extra bookkeeping involved of adjusting the reference count (which only gets worse in the presence of multithreading). Furthermore, using reference counting precludes the use of certain types fast of memory allocators, which can be a problem. It also tends to lead to heap fragmentation in its naive form, since objects are scattered through memory rather than tightly-packed, decreasing allocation times and causing poor locality.

The HotSpot JVM uses a variety of different techniques to do garbage collection, but its primary garbage collector is called a stop-and-copy collector. This collector works by allocating objects contiguously in memory next to one another, and allows for extremely fast (one or two assembly instructions) allocation of new objects. When space runs out, all of the new objects are GC'ed simultaneously, which usually kills off most of the new objects that were constructed. As a result, the GC is much faster than a typically reference-counting implementation, and ends up having better locality and better performance.

For a comparison of techniques in garbage collecting, along with a quick overview of how the GC in HotSpot works, you may want to check out these lecture slides from a compilers course that I taught last summer. You may also want to look at the HotSpot garbage collection white paper that goes into much more detail about how the garbage collector works, including ways of tuning the collector on an application-by-application basis.

Hope this helps!

这篇关于为什么JVM一旦引用计数达到0就会销毁资源？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！