使用Workflow 4.0時出現內存泄露SqlWorkflowInstanceStore和PersistableIdleAction.Unload

Question

這個特殊的問題讓我感到非常緊張。我想知道有沒有人遇到類似的問題。如果我加載一個工作流然後卸載它並執行內存快照，那麼結果是可預測的 - 我的工作流不再在內存中。但是，如果我加載工作流並將PersistableIdle操作設置爲PersistableIdleAction.Unload，並讓工作流處於空閒狀態，則即使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. 將實例存儲應用於Workflow1
5. 針對空閒，卸載，未處理異常等設置操作事件處理程序
6. 堅持工作流實例Ë
7. 運行工作流實例
8. 等待例如空閒（因延誤活動）
9. 確保卸載動作射擊
   - 在這一點上，我採取了第二個內存快照

從上面的圖片中可以清楚地看出，引用Workflow1的唯一對象是一些內部事件處理程序，我無法處理這些事件處理程序。

任何線索？

Answer 1

看起來像一個有趣的bug？我沒有你提到的分析器，所以有幾個問題。

• 您的調查是否由一些重大的內存使用問題驅動？

• 您是否確定卸載操作在分析時真正完成（vs將要異步發生等）？

• 看起來異步鏈是好的，但TdsParserStateObject可能是被泄露的真實對象。我注意到這個類有一個Dispose（）方法，但沒有實現IDisposable。因此，另一個想法是Dispose（）用於在某個特定的時間點手動「重置」或「回收」對象 - 但該時間點事實證明「尚未（卸載時間），但稍後」（例如，懶惰的回收。您的分析器是否讓您看到隨着時間的推移TdsParserStateObjects的數量是否在增加，以表明真正的泄漏？與「只有有限數量的物體，所以不是真正的泄漏」相反。