8

编辑 有关更多详细信息，请参阅问题底部的编辑说明。

原始问题

我有一个 CacheWrapper 类，它在MemoryCache内部创建并保存 .NET 类的一个实例。

MemoryCache将自身挂钩到 AppDomain 事件中，因此除非明确处置，否则它永远不会被垃圾收集。您可以使用以下代码验证这一点：

Func<bool, WeakReference> create = disposed => {
    var cache = new MemoryCache("my cache");
    if (disposed) { cache.Dispose(); }
    return new WeakReference(cache);
};

// with false, we loop forever. With true, we exit
var weakCache = create(false);
while (weakCache.IsAlive)
{
    "Still waiting...".Dump();
    Thread.Sleep(1000);
    GC.Collect();
    GC.WaitForPendingFinalizers();
}
"Cleaned up!".Dump();

由于这种行为，我相信我的 MemoryCache 实例应该被视为非托管资源。换句话说，我应该确保它在 CacheWrapper 的终结器中被处理（CacheWrapper 本身就是 Disposable 遵循标准的 Dispose(bool) 模式）。

但是，我发现当我的代码作为 ASP.NET 应用程序的一部分运行时，这会导致问题。卸载应用程序域时，终结器在我的 CacheWrapper 类上运行。这反过来又会尝试处置该MemoryCache实例。这是我遇到问题的地方。似乎Dispose尝试从 IIS 加载一些配置信息，但失败了（可能是因为我正在卸载应用程序域，但我不确定。这是我的堆栈转储：

MANAGED_STACK: 
    SP               IP               Function
    000000298835E6D0 0000000000000001 System_Web!System.Web.Hosting.UnsafeIISMethods.MgdGetSiteNameFromId(IntPtr, UInt32, IntPtr ByRef, Int32 ByRef)+0x2
    000000298835E7B0 000007F7C56C7F2F System_Web!System.Web.Configuration.ProcessHostConfigUtils.GetSiteNameFromId(UInt32)+0x7f
    000000298835E810 000007F7C56DCB68 System_Web!System.Web.Configuration.ProcessHostMapPath.MapPathCaching(System.String, System.Web.VirtualPath)+0x2a8
    000000298835E8C0 000007F7C5B9FD52 System_Web!System.Web.Hosting.HostingEnvironment.MapPathActual(System.Web.VirtualPath, Boolean)+0x142
    000000298835E940 000007F7C5B9FABB System_Web!System.Web.CachedPathData.GetPhysicalPath(System.Web.VirtualPath)+0x2b
    000000298835E9A0 000007F7C5B99E9E System_Web!System.Web.CachedPathData.GetConfigPathData(System.String)+0x2ce
    000000298835EB00 000007F7C5B99E19 System_Web!System.Web.CachedPathData.GetConfigPathData(System.String)+0x249
    000000298835EC60 000007F7C5BB008D System_Web!System.Web.Configuration.HttpConfigurationSystem.GetApplicationSection(System.String)+0x1d
    000000298835EC90 000007F7C5BAFDD6 System_Configuration!System.Configuration.ConfigurationManager.GetSection(System.String)+0x56
    000000298835ECC0 000007F7C63A11AE System_Runtime_Caching!Unknown+0x3e
    000000298835ED20 000007F7C63A1115 System_Runtime_Caching!Unknown+0x75
    000000298835ED60 000007F7C639C3C5 System_Runtime_Caching!Unknown+0xe5
    000000298835EDD0 000007F7C7628D86 System_Runtime_Caching!Unknown+0x86
    // my code here

有什么已知的解决方案吗？我认为我确实需要MemoryCache在终结器中处理它是正确的吗？

编辑

本文验证了 Dan Bryant 的回答，并讨论了许多有趣的细节。特别是，他介绍了 的情况StreamWriter，它面临与我的情况类似的情况，因为它想在处理时刷新它的缓冲区。这篇文章是这样说的：

一般来说，终结器可能不会访问托管对象。然而，对于相当复杂的软件来说，对关闭逻辑的支持是必要的。Windows.Forms 命名空间使用 Application.Exit 处理此问题，它会启动有序关闭。在设计库组件时，有一种支持关闭逻辑的方法与现有的逻辑相似的 IDisposable 集成是很有帮助的（这避免了在没有任何内置语言支持的情况下定义 IShutdownable 接口）。这通常是通过在调用 IDisposable.Dispose 时支持有序关闭来完成的，并且在没有调用时支持中止关闭。如果可以使用终结器尽可能有序地关闭，那就更好了。

微软也遇到了这个问题。StreamWriter 类拥有一个 Stream 对象；StreamWriter.Close 将刷新其缓冲区，然后调用 Stream.Close。但是，如果 StreamWriter 未关闭，则其终结器无法刷新其缓冲区。微软通过不给 StreamWriter 终结器“解决”了这个问题，希望程序员会注意到丢失的数据并推断出他们的错误。这是需要关闭逻辑的完美示例。

综上所述，我认为应该可以使用 Wea​​kReference 实现“托管终结”。基本上，让你的类在创建对象时注册一个对其自身的 WeakReference 和一个带有一些队列的 finalize 操作。然后，队列由后台线程或计时器监控，当它配对的 WeakReference 被收集时，它会调用适当的操作。当然，您必须小心，您的 finalize 操作不会无意中保留类本身，从而完全防止收集！

4

2 回答 2

7

您不能在终结器中处理托管对象，因为它们可能已经被终结（或者，正如您在此处看到的，环境的某些部分可能不再处于您期望的状态。）这意味着如果您包含必须显式处置的类，您的类也必须显式处置。没有办法“作弊”并使 Disposal 自动进行。不幸的是，在这种情况下，垃圾收集是一种泄漏的抽象。

于 2014-10-08T19:19:56.130 回答
1

我建议带有终结器的对象通常不应该暴露给外部世界，并且应该只持有对最终确定实际需要的东西的强烈引用，并且不暴露给外部世界中不希望它们用于的任何东西那个目的。面向公众的类型本身不应具有终结器，而应将清理逻辑封装在可终结类的私有实例中，其目的是封装此类逻辑。

只有当另一个对象被设计为与终结器接口时，终结器才真正有意义地尝试清理另一个对象拥有的资源。我想不出任何框架类在适当的钩子中设计的地方，但会提供一个例子，微软如何设计它们来做到这一点。

对象可以提供File具有线程安全订阅和取消订阅方法的事件，当File对象接收到Dispose调用或finalize请求时，这些方法将触发（首先通知最后一个订阅者）。该事件将在Finalize调用时间和封装文件实际关闭时间之间触发，并且可以被外部缓冲类用作它需要提供File它已接收但尚未传递的任何信息的信号。

请注意，为了使这样的事情正常和安全地工作，File对象的具有终结器的部分必须不向公众公开，并且它使用长弱引用来确保它是否在公共时运行-面向对象仍然存在，它将重新注册自己以进行最终确定。请注意，如果对WeakReference对象的唯一引用存储在可终结对象中，则即使该引用的实际目标仍然存在，Target如果可终结对象符合终结条件，则其属性可能会失效。有缺陷的设计，恕我直言，必须小心处理。

可以使用可以合作的终结器来设计对象（最简单的方法通常是在组中只有一个对象使用终结器），但如果事情不是为了与终结器合作而设计的，那么最好的可以做的通常是让终结器发出警报，指示“这个对象不应该是Disposed 但不是；因为它不是，资源将会泄漏，除了修复代码之外没有什么可做的以便将来妥善处理该对象”。

于 2014-10-09T18:43:25.690 回答