2012-05-22 27 views
2

我已經實現了Dispose ...無處不在支持它。我正在刪除所有事件處理程序。我沒有調用本地代碼。如何確定我的應用程序的哪部分內存泄漏?

我甚至遍歷每個字典,並將值設置爲null,並在所有項目上調用.Clear()。

問:

我怎麼能揣摩出我的代碼泄漏?

我第一次在隔夜的測試中發現泄漏。它使用固定數量的內存,因此它應該增長,然後變得有點靜態。然後我做了前臺線程顯示內存這樣的:

  if (key.KeyChar == 'g') 
      { 
       long pre = GC.GetTotalMemory(false); 
       long post = GC.GetTotalMemory(true); 
       Console.WriteLine("{2} Pre:{0} \tPost:{1}", pre, post, System.DateTime.Now); 
       GC.Collect(); 
       } 

我跑了好幾次(在幾個小時內,在同時按下「G」一次),並看到了越來越多。

+0

您是否在任何時候與COM對象進行交互? –

+4

是什麼讓你覺得它泄漏? – vcsjones

+4

將您的應用程序浸入水中並查看氣泡出來的位置。 – John

回答

1

請確保您使用

try 
{ 
} 
finally 
{ 
    youDisposableObject.Dispose(); 
} 

using (yourDisposableObject) {} 

的每一個對象,你執行了 「處置」

如果實施終結的一些對象,而不任何需要,刪除它們

,如果你仍然不能後修復它,你將不得不使用一個內存分析器

1

有介紹如何使用SOS.dll here做出來,更全面的一個here的文章。

根據您使用的Visual Studio版本(Premium或Ultimate),還可以使用普通的代碼分析工具來幫助查找代碼中可能導致內存泄漏的問題。 (詳細信息here

當然,在託管代碼中,內存泄漏與非託管代碼有點不同。在非託管代碼中,在您分配和釋放內存明確性的地方,內存泄漏是由於未能釋放內存而導致的。

在.NET中,內存泄漏來自掛在一個比預期長的對象上。只要遵循儘可能使用using聲明的最佳做法並仔細規劃變量的範圍,就可以在很大程度上避免這種情況。

1

我剛剛在我的c#應用程序中遇到了同樣的問題,並且使用了(實際上是試用版本) dotTrace memory profiler這非常有幫助。

它仍然需要一些時間來定位發生泄漏的實際代碼行。所以不要指望這個工具立即立即識別罪魁禍首。