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

Question

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

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

alt text http://www.rohland.co.za/wp-content/uploads/2010/04/Workflow_retention_graph.png

其他人可以验证这个问题吗？我的代码相当于以下内容：

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

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

任何线索？

Answer 1

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

• 您的调查是否受到一些重要内存使用问题的影响？

• 您在分析时是否确实完成了卸载操作（相对于异步发生等）？

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