垃圾收集保证

垃圾收集器有什么保证？

从我的研究中我设法发现：

• 如果仍然存在对内存的引用，则不会被垃圾收集
• If there is no reference:
  • 当GC是不确定的
  • 当 GC 启动时，终结器将在内存释放之前运行。
  • 无法保证终结器的顺序（因此不要假设父级将在子级之前运行）。

但我真正想知道的是：

是否保证所有内存最终都会被垃圾收集，并且终结器（析构函数）在对象上运行（假设程序正常退出）。例如，一个没有内存压力的应用程序，当它最终退出时，它会强制GC去查找所有对象并确保调用终结器（析构函数）（包括静态成员变量）吗？

我确实在此页面上找到了一段引用：http://www.c-sharpcorner.com/UploadFile/tkagarwal/MemoryManagementInNet11232005064832AM/MemoryManagementInNet.aspx http://www.c-sharpcorner.com/UploadFile/tkagarwal/MemoryManagementInNet11232005064832AM/MemoryManagementInNet.aspx

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

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

我还找到了有关以下内容的文档：关键终结器对象 http://msdn.microsoft.com/en-us/library/system.runtime.constrainedexecution.criticalfinalizerobject.aspx

是否能保证所有内存 最终会被垃圾收集 和终结器（析构函数）运行 对象（假设程序 很好地退出）。

不。从对象.Finalize http://msdn.microsoft.com/en-us/library/system.object.finalize.aspx文档清楚地表明，如果出现以下情况，则可能不会调用终结器：

• 其他一些终结器无法正确完成：

  另一个终结器无限期地阻塞 （进入无限循环，尝试 获得一个它永远无法获得的锁并且 很快）。因为运行时尝试 运行终结器直至完成，其他 终结器可能不会被调用，如果 终结器无限期地阻塞。

• 其他一些终结器创建更多 可终结的对象，使其 不可能全部敲定 可终结的对象：

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

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

  如果 Finalize 或覆盖 Finalize 抛出异常，并且运行时 不是由应用程序托管的 覆盖默认策略， 运行时终止进程并且没有 主动 try-finally 块或 终结器被执行。这种行为 确保过程完整性，如果 终结器无法释放或销毁 资源。

话虽如此，除非绝对必要，否则您不想使用终结器的原因还有很多。

• 他们减慢了垃圾收集器的速度 （甚至可以减慢速度 下降太多以至于记忆力下降 用完后立即回收）。
• 他们在另一个线程上运行，带来 多线程问题发挥作用。
• 他们不是在一个 确定性顺序。
• 他们可以复活曾经存在过的物体 已经最终确定（并且不会是 除非明确再次确定 重新注册以最终确定）。