强制垃圾收集或反射到私有字段，哪个更邪恶？

Question

我们有一个第三方库，它在内部使用 SafeHandle 来处理非托管资源。在某些错误情况下，有必要处置该对象并重新创建它。但是，处置实现中存在一个错误，该错误会阻止在这些情况的子集中关闭句柄。这会阻止新对象在其终结器运行之前成功创建。

在我们修复第三方代码之前，已经提出了两种解决方案（都是邪恶的）来解决这个问题：

1. 运行 GC.Collect 来运行终结器并清理对象< /p>

2. 使用反射获取 Handle，如果 dispose 失败则将其关闭

其中哪一个危害较小，为什么？ 还有其他我们没有考虑过的比这两种方法更邪恶的方法吗？

Answer 1

我赞成私人反思。这是一个本地化的错误，因此解决方案也应该是本地化的。而且您的代码的用途也更加清晰。您可能可以添加一些测试，以便在错误修复后注意到。因此，一旦不再需要，黑客就可以轻松删除。

...
thirdPartyObject.Dispose();
ThirdPartyDisposeBugWorkaround(thirdPartyObject);
...

void ThirdPartyDisposeBugWorkaround(ThirdPartyClass thirdPartyObject)
{
   //Do private reflection here
}

另一方面，强制 GC 会产生全局影响。干扰 GC 的原因有很多（其中大部分都是不好的）。您的代码的作用不太明显。因此，即使错误得到修复，调用也可能会保留。

旧的新事物：不要使用全局状态来管理本地问题

Answer 2

我会进行反思，但要确保你有错误处理，明确出了什么问题，请记住，直到几年后，错误可能不会被触发，你的开发团队可能已经转变，没有人记得这个古怪的黑客。

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);
}

Answer 3

首先选择有效的。如果它们都有效，请选择对系统影响最小的一个。 Gc.Collect 更像是贯穿整个应用程序的锤子。虽然您的反射代码很脆弱，但影响应该很小。

Answer 4

如果它没有标记为密封，您可以继承它并实现您自己的处置。至于反射与GC，我肯定会使用反射。正如其他人所说，GC 可能无法按预期工作。它可以进行集合迭代，但实际上不会释放您的句柄。

我想指出的是：如果其他东西仍然引用了这个 SafeHandle，并且您释放了它，则可以轻松地将其他错误引入您的系统。

Answer 5

继续讨论“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.