Reference
Why using finalizers is a bad idea
当在一个类中使用了另外一个实现了 IDisposable 的类作为一个成员属性时, 此时这个类就有必要也去实现IDisposable接口, 以确保在合适的实际释放非托管资源, 到底该如何正确的实现这个接口呢? 当然这只是需要实现IDisposable接口其中一种情况
完整示例
示例的 Foo 类中包含了一个 Stream 类型的 _stream 成员, 因此需要为Foo类实现IDisposable模式
public class Foo : IDisposable { private bool _disposed; private readonly Stream? _stream; public Foo() { _stream = File.Create("1.txt", 2048); } ~Foo() { CleanupUnmanagedResources(); } private void CleanupUnmanagedResources() { if (_disposed) return; // 释放非托管资源 _stream?.Dispose(); _disposed = true; } public void Dispose() { CleanupUnmanagedResources(); GC.SuppressFinalize(this); } }
为什么要实现Foo析构函数
因为人性的弱点(??)
哈哈, 其实因为我们在使用 Foo 时可能会忘记手动调用其 Dispose 方法, 这个时候如果没有析构函数的话, 很可能导致资源永远得不到释放最终酿成内存泄漏的惨剧.
当然啦, 在析构函数中释放非托管资源可能会给 GC 带来额外的开销, 所以最好的做法是依然是使用 using 块保证能够及时的调用Dispose方法, 这里使用析构函数只是为了防止意外的发生. 至于为什么说在析构函数中释放非托管资源会导致额外的 GC 开销呢, 这涉及到GC回收过程,GC在处理包含析构函数的类时不会立即将此类回收, 而是会被GC标记为下一代, 这样这个被标记为下一代的类只有在GC决定回收下一代的垃圾对象时, 才会被真正回收掉, 这样一来就会导致额外的内存和性能开销了.
Dispose方法中为什么要调用GC.SuppressFinalize
GC.SuppressFinalize 方法可以告诉 GC 不需要在调用此类的析构函数(Finalizers)了;
因为在 Foo 类的析构函数中调用了Foo.CleanupUnmanagedResources方法, 当 GC 回收此类调用此类析构函数时, 有可能会导致两次调用Foo.CleanupUnmanagedResources(第一次是 Dispose 方法中调用的)导致额外的开销,
所以当我们手动调用了Foo.Dispose(通过是通过 using 语法糖)后, 就需要告诉 GC , "你回收我的时候用不着调用我的析构函数了, 该释放的资源我早就释放掉了已经", 转换成代码就是GC.SuppressFinalize
以上就是C#实现IDisposable接口释放非托管资源的详细内容，更多关于C# IDisposable接口释放资源的资料请关注其它相关文章！
查看更多关于C#实现IDisposable接口释放非托管资源的详细内容...