编程语言
首页 > 编程语言> > c# – 请问GC.SuppressFinalize有什么实质性影响吗?

c# – 请问GC.SuppressFinalize有什么实质性影响吗?

作者:互联网

是的,我知道如何使用GC.SuppressFinalize() – 它已解释为here.我已多次读过使用GC.SuppressFinalize()从终结队列中删除对象,并假设这很好,因为它减轻了GC的额外工作量叫终结者.

所以我制作了这个(通常是无用的)代码,其中类实现了IDisposable,如链接回答:

public class MyClass : IDisposable
{
   ~MyClass()
   {
       Dispose(false);
   }

   public void Dispose()
   {
       Dispose(true);
       GC.SuppressFinalize(this);
   }

   private bool disposed = false;

   protected virtual void Dispose(bool disposing)
   {
       if (!disposed)
       {
           System.Threading.Thread.Sleep(0);
           disposed = true;
       }
   }
}

在这里,我使用Sleep(0)来模仿一些简短的非托管工作.请注意,由于类中的布尔字段,此非托管工作永远不会执行多次 – 即使我多次调用Dispose()或者首先处理对象然后最终确定 – 在任何这些情况下,“非托管工作”是只执行一次.

这是我用于测量的代码:

var start = DateTime.UtcNow;
var objs = new List<Object>();
for (int i = 0; i < 1000 * 1000 * 10; i++)
{
    using (var obj = new MyClass())
    {
        objs.Add(obj);
    }
}
objs = null;
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
var duration = (DateTime.UtcNow - start).TotalMilliseconds;
Console.WriteLine(duration.ToString());

是的,我将刚刚处理好的对象添加到List中.

所以我运行上面的代码,它运行在12.01秒(发布,没有调试器).然后我注释掉GC.SuppressFinalize()调用并再次运行代码,它运行在13.99秒.

调用GC.SuppressFinalize()的代码速度提高了14.1%.即使在这个荒谬的情况下,所有的一切都是为了强调GC(你很少用行中的终结器制作一千万个物体,不是吗?),差异大约是14%.

我想在现实场景中,只有一小部分对象首先具有终结器,而且这些对象也没有大量创建,整体系统性能的差异可以忽略不计.

我错过了什么吗?是否有一个现实的场景,我会看到使用GC.SuppressFinalize()的显着好处?

解决方法:

举一个简单的例子:

protected virtual void Dispose(bool disposing)
{
    if(!disposing)
    {
        HardStopSystem(
            $"Critical failure: an instance of '{GetType().Name}' was not disposed");
    }
}

只有在击中终结器时才会达到此目的.是的,它是强制的和人为的,但是:这是基于我在许多系统中看到的真实代码,在这些系统中,事情被正确处理是至关重要的.

另一个例子包括确保非托管指针之类的东西不会被释放两次(这会失败).现在是的,你可以设置一个标记来说“不再这样做”,但是你会进入不可变类型的话题等等.

the difference in overall system performance would be negligible.

这在很大程度上取决于场景.最终,终结者更多的是正确性而不是表现. IDisposable与性能更相关,因为它与及时性有关.

标签:c,net,garbage-collection,idisposable,suppressfinalize
来源: https://codeday.me/bug/20190527/1162531.html