垃圾回收保证 [英] Garbage collection Guarantees

问题描述

垃圾收集器有什么保证?

What guarantees are the for the garbage collector?

通过研究，我设法找到了

From my research I have managed to find:

• 如果仍然有对内存的引用，则不会对其进行垃圾收集
• 如果没有参考:
  • 当它是GC时是不确定的
  • 当GC踢入终结器时，将在释放内存之前运行.
  • 不能保证终结器的顺序(因此不要假设父级将在子级之前运行).

  但是我真正想知道的是:

  But what I really want to know is:

  是否可以保证所有内存最终都将被垃圾回收，并且终结器(析构函数)将在该对象上运行(假设程序已退出).例如，当一个应用程序最终退出时没有内存压力时，它将迫使GC去查找所有对象并确保调用了终结器(析构函数)(包括静态成员变量)吗?

  Is there a guarantee that all memory will eventually be garbage collected and the finalizer (destructor) run on the object (assuming the program exited nicely). For example an application with no memory pressure when it eventually exits will it force the GC to go find all objects and make sure the finalizer (destructor) is called (including static member variables)?

  我确实在此页面上找到了报价: http://www.c-sharpcorner.com/UploadFile/tkagarwal/MemoryManagementInNet11232005064832AM/MemoryManagementInNet.aspx

  I did find a quote on this page: http://www.c-sharpcorner.com/UploadFile/tkagarwal/MemoryManagementInNet11232005064832AM/MemoryManagementInNet.aspx

  此外，默认情况下，退出应用程序时不为无法访问的对象调用Finalize方法，以便该应用程序可以快速终止.

  In addition, by default, Finalize methods are not called for unreachable objects when an application exits so that the application may terminate quickly.

  但是我不确定这句话的权威性.

  But I am not sure how authoritative this quote is.

  我还找到了以下文档: CriticalFinalizerObject

  I also found documentation on: CriticalFinalizerObject

  推荐答案

  是否有所有内存的保证最终将被垃圾收集而终结器(析构函数)在对象(假设程序顺利退出).

  Is there a guarantee that all memory will eventually be garbage collected and the finalizer (destructor) run on the object (assuming the program exited nicely).

  不.从 Object.Finalize 文档中，很明显终结器可能不会被调用，如果

  No. From the Object.Finalize documentation it is clear that finalizers may not be invoked if

  • 其他一些终结器无法正常完成:

  • Some other finalizers don't finish properly:

  另一个终结器无限期地阻塞(进入无限循环，尝试获得它永远无法获得的锁，并且很快).因为运行时尝试运行终结器以完成任务，其他如果终结器无限期地阻塞.

  Another finalizer blocks indefinitely (goes into an infinite loop, tries to obtain a lock it can never obtain and so on). Because the runtime attempts to run finalizers to completion, other finalizers might not be called if a finalizer blocks indefinitely.

• 其他一些终结者可以创造更多可终结的对象，使其成为不可能全部完成可终结对象:

• Some other finalizers create more finalizable objects, making it impossible to finalize all finalizable objects:

  运行时继续完成关机期间仅在可终结对象的数量继续减少.

  The runtime continues to Finalize objects during shutdown only while the number of finalizable objects continues to decrease.

• 其他一些终结器抛出异常:

• Some other finalizers throw exceptions:

  如果完成或覆盖完成引发异常，运行时没有由以下应用程序托管覆盖默认策略运行时终止进程，并且没有活动的try-finally块或终结器被执行.这种行为如果终结器无法释放或破坏资源.

  If Finalize or an override of Finalize throws an exception, and the runtime is not hosted by an application that overrides the default policy, the runtime terminates the process and no active try-finally blocks or finalizers are executed. This behavior ensures process integrity if the finalizer cannot free or destroy resources.

话虽这么说，除非有严格的必要，否则还有很多原因您不想使用终结器.

That being said, there are more reasons why you wouldn't want to use finalizers unless strictly necessary.

• 他们减慢了垃圾收集器的速度(甚至可以减慢它的速度下降太多以至于内存不足尽快回收).
• 它们在另一个线程上运行，多线程问题发挥作用.
• 它们不是在确定性顺序.
• 他们可以复活原本是已经完成(不会除非有明确说明，否则将再次完成重新注册以便最终确定.

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