workflow-foundation - 使用 Workflow 4.0 SqlWorkflowInstanceStore 和 PersistableIdleAction.Unload 时的内存泄漏

Question

这个特殊的问题让我发疯。我想知道是否有人遇到过类似的问题。如果我加载一个工作流然后卸载它并执行内存快照，那么结果是可以预测的——我的工作流不再在内存中。但是，如果我加载工作流并将 PersistableIdle 操作设置为 PersistableIdleAction.Unload 并让工作流空闲，即使 Unload 操作触发，工作流仍保留在内存中。

我使用 ANTS Memory Profiler 来调试这个问题。这是输出的对象保留图，显示内部对象挂在我的工作流实例上。

_{（来源：rohland.co.za）}

其他人可以验证这个问题吗？我的代码如下：

1. 创建 SqlWorkflowInstanceStore 并设置锁所有者句柄
   ——此时我拍摄内存快照
2. 创建 Workflow1 的实例
3. 设置 PersistableIdle 操作
4. 将 instancestore 应用到 Workflow1
5. 为 Idle、Unload、UnhandledException 等设置操作事件处理程序。
6. 持久化工作流实例
7. 运行工作流实例
8. 等待实例空闲（由延迟活动引起）
9. 确保触发了 Unload 操作
   ——此时我拍摄了第二个内存快照

从上图中可以清楚地看出，唯一引用 Workflow1 的对象是一些我无法处理的内部事件处理程序结果。

有什么线索吗？

Answer 1

看起来像一个有趣的错误？我没有你提到的探查器，所以有几个问题。

• 您的调查是由一些重大的内存使用问题驱动的吗？

• 您有多确定卸载操作在分析时真正完成（与即将异步发生等相比）？

• 看起来异步链没问题，但 TdsParserStateObject 可能是被泄露的真实对象。我注意到该类有一个 Dispose() 方法，但没有实现 IDisposable。所以另一个想法是 Dispose() 用于在某个不同的时间点手动“重置”或“回收”对象 - 但该时间点结果是“尚未（卸载时间）但稍后”，例如懒惰回收。您的分析器是否让您查看 TdsParserStateObjects 的数量是否随着时间的推移而增加，以表明那里存在真正的泄漏？与“只是有限数量的对象而不是真正的泄漏”相反。