使用 Workflow 4.0 SqlWorkflowInstanceStore 和 PersistableIdleAction.Unload 时出现内存泄漏

Question

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

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

_{（来源：rohland.co.za< /a>)}

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

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

从上图中，很明显，引用 Workflow1 的唯一对象是一些我无法处理的内部事件处理程序结果。

有什么线索吗？

Answer 1

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

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

• 您有多确定卸载操作在分析时确实完成（相对于即将异步发生等）？

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