析构函数不能保证被调用

本文关键字：调用 不能 析构函数 | 更新日期: 2023-09-27 18:02:34

我看到下面的引用"不能保证调用构造函数"，这让我有点害怕。

它接着说，甚至一个try finally块也可能被中断，从而导致内存泄漏。它确实提供了一个解决方案，要么将您的代码放在CER(约束执行区域)中，要么从CriticalFinalizerObject派生。

我的问题是

  1. 如果有的话，使用CriticalFinalizerObject的权衡是什么?
  2. 你有没有发现从CriticalFinalizerObject衍生出来的东西真的有用?
  3. 我应该只担心使用这个，当我开始运行到内存泄漏?

析构函数不能保证被调用

为什么要依赖析构函数?大多数时候你根本不需要它们。

也许可以看看idisposable和Dispose Pattern。

这里有一些帮助我理解这个主题的链接

->每个人对垃圾回收的想法都是错误的

->如何实现dispose Pattern

->实现Finalize和Dispose清理非托管资源

关于问题#3:内存泄漏通常由以下因素引起:

  • 未释放非托管资源。对于这些，使用IDisposable(在终结器中回调Dispose())是最好的方法。

  • 管理对象的引用被维护，因为其他对象仍然指向它们，即使它们应该被删除。IHMO，这更多的是代码质量问题，而不是低级别的垃圾收集问题。

除非您遇到实际的内存泄漏，否则您甚至不应该担心它，也不要试图强制执行任何行为。

我建议对所有需要销毁的资源使用IDisposable接口，并在using块中使用它们。

一般来说，正常终结器和临界终结器之间的区别只在AppDomain卸载时变得重要。由于大多数非托管资源在进程卸载时自动消失，如果您想在保持进程运行的同时干净地卸载AppDomain，则通常只需要担心临界终结。

相关文章：