c# - 在终结器中调用 GC.SuppressFinalize 是否无害？

Question

因为 finalizer/IDisposable 和所谓的“IDisposable 模式”主题往往会引发大量故作姿态、武断和好战的观点(不是-分别是 here 、 here 、 here 等等)，我真的很犹豫要问这个问题。希望先发制人那些老生常谈的辩论，我一直在回答一个非常简单的问题，这个问题在 StackOverflow 上似乎没有一个简洁的答案......

一旦对象的终结器开始执行，调用 GC.SuppressFinalize(this) 是否空洞？更具体或更有用(当然)，从终结器本身内部调用 GC.SuppressFinalize(this) 是否无害？ (同样，我们不在这里讨论任何“为什么”)

换句话说，除了调用 API 的开销以及在对象 header 中适当设置标志之外，是否存在任何不良、不需要或其他有形的正确性或性能影响？

Answer 1

当然，完全避免终结器并使用 SafeHandle 会更好，正如现代习语所要求的那样。然后所有这些关于终结器的东西都变得毫无意义。

也就是说，尽管这样做很明智，但从终结器调用 GC.SuppressFinalize() 是绝对安全的。 The documentation for the method描述该方法的作用:

This method sets a bit in the object header of obj, which the runtime checks when calling finalizers.

运行时实际上也可能在 GC 操作期间检查此位，即当发现无法访问的对象时，该对象的终结器将被放入终结器队列。如果在那个时候设置，finalizer 甚至不会在队列中结束。

稍后再次检查它，在调用终结器本身之前，也可以避免对象的终结，如果结果是某个其他对象的终结器最终处置了它，即使该对象的终结器已放入终结队列中。

这两项检查都发生在调用终结器之前。一旦调用终结器，对象中的位就没有用处了。设置它是无害的，但不会完成任何事情。

顺便说一句:请注意，过去的 .NET 实现使用 Finalizer 和 FReachable 队列。当一个对象被创建时，如果它有一个终结器，它将被移动到 Finalizer 队列中。一旦对象不可访问，它将被移动到 FReachable 队列以供稍后完成。调用 SuppressFinalize() 将从 Finalizer 队列中删除对象。到终结器运行时，对象不再在此队列中，因此 SuppressFinalize() 调用将是 NOP，同样无害。

现在，也就是说，您的问题很宽泛:“……是否存在任何不好的、不需要的或其他有形的正确性或性能影响？”。其中大部分是旁观者的眼睛。我认为调用 GC.SuppressFinalize() 的终结器是不正确的。所以，这对我来说是一个“有形的正确性效果”。我还发现偏离已发布的、公认的标准模式的代码是“不需要的”。如果问题中没有更具体的标准来约束它，那部分问题的答案可以是"is"、“否”、“有时”等中的任何一个。

事实上，您的问题是重复的，但没有人愿意回答:Calling GC.SuppressFinalize() from within a finalizer .不过，我确实找到了评论线索，尤其是埃里克·利珀特 (Eric Lippert) 的贡献:

Your supposition is that the unnecessary call to SuppressFinalize is the error in your plan. That's not the problem; the problem is the disposal of managed resources on the finalizer thread. Recall to your mind that finalizers run on their own thread, and that managed resources can be thread-affinitized, and now start to imagine the horrors that could result. Moreover: finalizers run in arbitrary order. A managed object disposed on the finalizer thread might have already been finalized; now you are possibly running finalization logic twice on one object; is it robust to that scenario? – Eric Lippert Mar 31 '16 at 21:58 1

Writing a correct finalizer is extraordinarily difficult and I recommend against you trying ever, ideally, but definitely hold off until you understand the pattern better. If you are not sufficiently scared yet, my series of articles on the subject might put more fear into you: ericlippert.com/2015/05/18/… – Eric Lippert Mar 31 '16 at 21:59

…

@Tom: The question is "I'm using the dispose pattern completely wrong; is this particular part of what I'm doing wrong?" No, the whole thing is wrong from the very first sentence. You don't use Dispose to dispose managed resources, and you certainly don't use a finalizer for that. That's the problem here. Is there anything wrong, per se, with calling SuppressFinalize from a finalizer? Well, it will work, but there should not be a situation in which that is the correct thing to do, so whether it works or not should be irrelevant. – Eric Lippert Jul 7 at 14:17

@Tom: Also, why do you call SuppressFinalize in the first place? Only because it is a performance optimization. But under what circumstances is it an optimization when called from the finalizer thread? Only when you've failed to make that optimization from the main thread! That's the place to do that optimization! – Eric Lippert Jul 7 at 14:24

恕我直言，这些评论将主要问题带到了一个很好的角度:询问从终结器调用 SuppressFinalize() 是否安全是错误的问题。如果您已经到了不得不问这个问题的地步，那么代码就已经错了，而且问题的答案可能并不那么相关。正确的方法是修复代码，这样您就不必问这个问题。

最后，虽然不是完全相同的问题，但我认为还值得指出的是，通常的指导是在 Dispose() 的末尾调用 SuppressFinalize()方法可能不正确。如果调用，则应在 Dispose() 方法的开始 处调用。参见 Be Careful Where You Put GC.SuppressFinalize