GC.WaitForPendingFinalizers（）在哪些情况下会在.NET中阻塞？

从MSDN文档中引用以下内容：

运行终结器的线程未指定，因此无法保证此方法将终止

我真的不明白这句话。在哪些情况下，此方法不终止？这与终结器运行的线程有什么关系？为什么他们说线程是“未指定的”

关于终结器线程，我假设以下是正确的（？）

• 只有一个终结器线程
• 终结器始终在单独的线程上运行（即，从不在主线程或任何其他用户创建的线程上运行）

---

注意：我可以想象，当一个终结器阻塞时，此方法将阻塞，但无论终结器使用哪个线程，此问题都存在。

首先，您通常不需要在GC类中使用方法，但SuppressFinalize可能除外。大多数其他方法通常会使应用程序的性能最差，而不是更好

但是，为了回答您的问题，据我所知，在执行收集时，终结器的垃圾收集器会保存一个内部列表，以运行它们，，并且它们都在同一个线程上依次运行。这意味着，如果一个终结器阻塞，那么我猜这个方法也会阻塞

当app domain关闭时，所有终结器的完成都有一个时间限制，在这种情况下，我想这并不重要。

来源：

Finalize方法可能无法运行到完成，或者可能无法在运行时运行 在下列特殊情况下：

• 另一个终结器无限期阻塞（进入无限循环， 尝试获取它永远无法获得的锁，以此类推）。因为 运行时尝试运行终结器以完成其他终结器 如果终结器无限期阻止，则可能不会调用

• 进程终止，而不给运行时清理的机会 向上的在本例中，运行时的第一个进程通知 终止是DLL_进程_分离通知

---

好的，但是为什么文档明确指出“运行终结器的线程未指定”？仅仅写“无法保证此方法会终止（因为阻止终结器）”？这难道还不够吗？我认为这意味着CLR团队希望将来有权更改实现细节，他们不希望您依赖于它今天的工作方式。事实上，它们在自己的线程上运行（不是称为GC.Collect的线程）。在Richter的CLR via C#中，我相信他提到（很像Shahar所写的）将来，CLR可能会使用多个终结器线程。我手边没有这本书，但我认为可以在书中找到一个更深入的讨论，也许可以更好地回答你的问题。请参阅对理查德·摩根答案的评论。