使用遠程性能監視器幫助查找泄漏

Question

我試圖在使用遠程性能監視器的Compact Framework應用程序中發現內存泄漏的來源。我設法刪除了一些與刷子和其他圖形對象有關的小問題，但我仍然不清楚導致主要問題的原因。

在這一點上，似乎永遠不會回到原始計數的唯一對象是System.String對象。我覺得這很奇怪，因爲我會認爲爲了使這些對象不被收集，包含它們的對象將不得不保留，但是沒有其他類型的對象似乎隨着System.Strings。

我想知道哪些新的String對象是應用程序返回到其原始狀態（即登錄屏幕）後剩下的對象。問題是，最初，應用程序加載大約2200個字符串對象，然後在處理「X」之後，它增加了另外70個從未收集的東西。我不知道如何識別這70個新的物體，以便找出誰正在抓住他們並作出適當的更正。

有沒有人有沒有收集字符串的經驗？有什麼辦法可以將在過程「X」中創建的新對象與應用程序最初需要的新對象分開，以便我可以知道哪些是泄漏？任何意見，將不勝感激。

感謝

**更新

好吧......有事情很奇怪的東西。我開始懷疑是否有泄漏。

假設我在作爲應用程序的原始起點的登錄屏幕上記錄了快照。想象一下，此時在內存中有1000個字符串對象。現在，如果我登錄並從菜單中選擇一個選項，我將在加載新屏幕後拍攝快照。假設加載這個表單增加了50個對象的字符串數量。當我在登錄屏幕上註銷並再次拍攝快照時，僅收集了其中的25個對象，其餘的將從此保留在內存中。

奇怪的是，如果我不斷重複這個過程，不會再有字符串對象累積。而不是字符串數量增加50，在這一點上只會添加25個，並且一旦我回到登錄屏幕就會收集到相同的25個字符串。我在想，如果這是一個實際的泄漏，那麼每次打開該屏幕時，字符串數將永久增加25，但這只是第一次發生。

這發生在我打開的每個新屏幕上。起初，總體字符串計數有一個小的永久性增加，但是一旦我加載了特定的屏幕，一旦我回到登錄屏幕，在執行過程中任何字符串計數的增加都會被收集。

所有這些讓我相信，也許這些字符串是CLR內部工作的一部分或類似的東西。它可能是由運行時完成的某種緩存嗎？也許它是存儲我的字符串常量更快加載？像那樣的東西？我希望這不是太混亂。

Answer 1

如果您使用CF 3.5，則使用the CLR Profiler而不是RPM。它會告訴你所有的物體和產生它們的根源。它可以讓你回溯根樹，找出它們的分配位置。

編輯

所以你說，你是不是真正得到奧姆斯或任何aberrent行爲？聽起來就像你試圖在沒有必要時進行優化。這些字符串可能是JITter創建的表單標題等，如果/收集對象時會收集。但是，如果你實際上沒有看到內存問題，它們確實不是非常重要。