我们有一个第三方库，它在内部使用 SafeHandle 来处理非托管资源。在某些错误情况下，有必要处理对象并重新创建它。但是，在 dispose 实现中存在一个错误，该错误会阻止 Handle 在这些情况的子集中关闭。这会阻止新对象在其终结器运行之前成功创建。
已经提出了两种解决方案（都是邪恶的）来解决这个问题，直到我们可以修复第三方代码：
运行GC.Collect 以使终结器运行并清理对象
使用反射获取 Handle 并在 dispose 失败时将其关闭
其中哪一个不那么邪恶，为什么？ 有没有其他我们没有考虑过的方法比这两种方法更邪恶？
【问题讨论】：
标签： c# .net reflection garbage-collection private-members
我赞成私人反思。这是一个本地化的错误，所以解决方案也应该是本地的。你的代码打算做什么更清楚了。而且您可能可以添加一些测试，一旦错误得到修复就会注意到。因此，一旦不再需要该 hack，就可以轻松删除它。
...
thirdPartyObject.Dispose();
ThirdPartyDisposeBugWorkaround(thirdPartyObject);
...
void ThirdPartyDisposeBugWorkaround(ThirdPartyClass thirdPartyObject)
{
//Do private reflection here
}
另一方面，强制 GC 具有全局效果。干扰 GC 的原因有很多（其中大部分是不好的）。您的代码的作用不太明显。因此，即使修复了错误，也可能会保留调用。
Old New Thing: Don't use global state to manage a local problem
【讨论】：
GC.Collect 几乎总是错误的做法。以及链接到 Raymond 博客的奖励积分。但无论您决定如何，重要的是广泛记录它。
我会进行反思，但请确保您对其进行了错误处理，以明确指出问题所在，请记住，该错误可能要到几年后才会触发，并且您的开发团队可能会翻身而没有人记得这个古怪的黑客。
try
{
.. hacky reflection ..
}
catch(Exception ex)
{
throw new Exception("Reflection on private field 'Xyz' of 3rd Party Component 'Abc' failed. Was 'Abc' updated? Reflection is used due to bug in 'Dispose' implementation.", ex);
}
【讨论】：
Debug.Assert。如果我要抛出异常，我肯定不会抛出System.Exception。也许InvalidOperationException？
ExceptionUtil.Rethrow 的帮助器类，它产生了一个与原始类型相同的新异常，在添加更多信息时很有用。我当然不想使用Debug.Assert，因为如果可以独立于应用程序更新第 3 方库（这当然是一个可怕的想法，但人们会做愚蠢的事情），那么这是生产中会发生的异常。
Exception 类... ;-)
首先选择一个有效的。如果他们都工作，则选择对系统影响最小的那个。 Gc.Collect 在整个应用程序中更像是一把锤子。您的反射代码很脆弱，但影响应该很小。
【讨论】：
如果它没有被标记为密封，你可以继承它并实现你自己的 dispose。至于反射与 GC，我肯定会使用反射。正如其他人所说，GC 可能无法按预期工作。它可以进行集合迭代，但实际上不会释放您的句柄。
我想指出：如果其他东西仍然引用此 SafeHandle，并且您释放它，您很容易将其他错误引入您的系统。
【讨论】：
将“CodeInChaos”论据向前推进，为什么不要求在特定代进行收集。
GC.GetGeneration(Object obj) 将返回对象所在的代和GC.Collect(Int32 gen)。
例如：
Int32 generation = GC.GetGeneration(theObject);
theObject = null;
GC.Collect(generation);
GC.WaitForPendingFinalizers();
GC.Collect(generation); // this is req because first collect puts thisObject on freachable queue not // garbaged yet.
【讨论】：