原文來自互聯(lián)網(wǎng)，由長沙DotNET技術社區(qū)編譯。

本文來源：https://michaelscodingspot.com/find-fix-and-avoid-memory-leaks-in-c-net-8-best-practices/

從事大型企業(yè)項目的任何人都知道內(nèi)存泄漏就像是大型酒店中的老鼠。當它們很少時，您可能不會注意到，但是您必須始終保持警惕，以防它們過多，闖入廚房并制造混亂。

查找，修復和學習避免內(nèi)存泄漏是一項重要技能。

我將列出我和高級.NET開發(fā)人員為我提供建議的8種最佳實踐技術，這些技術將教您檢測應用程序中何時存在內(nèi)存泄漏問題，查找特定的內(nèi)存泄漏并進行修復。最后，我將介紹監(jiān)視和報告已部署程序的內(nèi)存泄漏的策略。

定義.NET中的內(nèi)存泄漏

在垃圾收集環(huán)境中，術語“內(nèi)存泄漏”有點違反直覺。當有垃圾收集器（GC）負責收集所有內(nèi)容時，我的內(nèi)存為何還會泄漏？

有兩個相關的核心原因。第一個核心原因是當您具有仍被引用但實際上未使用的對象時。由于已引用它們，垃圾收集器將不會收集它們，并且它們將永久保留，占用內(nèi)存。例如，當您注冊事件但從不注銷時，可能會發(fā)生這種情況。

第二個原因是當您以某種方式分配非托管內(nèi)存（沒有垃圾回收）并且不釋放它時。這并不難做到。.NET本身有很多分配非托管內(nèi)存的類。幾乎所有涉及流，圖形，文件系統(tǒng)或網(wǎng)絡調(diào)用的操作都是在后臺進行的。通常，這些類實現(xiàn)** Dispose **方法，該方法釋放內(nèi)存（稍后再討論）。您可以使用特殊的.NET類（如Marshal）或PInvoke（有一個進一步的示例）輕松地自己分配非托管內(nèi)存。

讓我們進入我的最佳實踐技術列表：

1.使用診斷工具窗口檢測內(nèi)存泄漏問題

如果您去調(diào)試 | Windows | 顯示診斷工具，您將看到此窗口。如果您像我一樣，則可能在安裝Visual Studio之后看到了此工具窗口，立即關閉了它，再也沒有想到它。診斷工具窗口可能會非常有用。它可以輕松地幫助您檢測兩個問題：內(nèi)存泄漏和GC壓力。

當您有內(nèi)存泄漏時，“進程內(nèi)存”圖如下所示：

圖片

從頂部的黃線可以看到GC正在嘗試釋放內(nèi)存，但它仍在不斷上升。

當您具有GC Pressure時，過程內(nèi)存圖如下所示：

圖片

“ GC壓力”是在創(chuàng)建新對象并將它們處置得太快而導致垃圾收集器無法跟上時。如圖所示，內(nèi)存已接近極限，GC突發(fā)非常頻繁。

您將無法通過這種方式找到特定的內(nèi)存泄漏，但是您可以檢測到內(nèi)存泄漏問題，這本身就很有用。在Enterprise Visual Studio中，“診斷”窗口還包括一個內(nèi)置的內(nèi)存探查器，該探查器確實可以查找特定的泄漏。我們將在最佳實踐＃3中討論內(nèi)存分析。

2.使用任務管理器，Process Explorer或PerfMon檢測內(nèi)存泄漏問題

檢測主要內(nèi)存泄漏問題的第二種最簡單方法是使用任務管理器或Process Explorer（來自SysInternals）。這些工具可以顯示您的進程使用的內(nèi)存量。如果它隨著時間不斷增加，則可能是內(nèi)存泄漏。

圖片

性能監(jiān)視器是有點難以利用^[1]，但能證明你的內(nèi)存使用量隨時間的一個很好的曲線圖。這是我的應用程序的圖形，它不停地分配內(nèi)存而不釋放它。我正在使用過程 | 專用字節(jié)計數(shù)器。

圖片

請注意，此方法眾所周知是不可靠的。您可能只是因為GC尚未收集內(nèi)存而增加了內(nèi)存使用量。還有共享內(nèi)存和私有內(nèi)存的問題，因此您可能會錯過內(nèi)存泄漏和/或診斷不是您自己的內(nèi)存泄漏（說明^[2]）。最后，您可能將內(nèi)存泄漏誤認為是GC Pressure。在這種情況下，您不會發(fā)生內(nèi)存泄漏，但是創(chuàng)建和處理對象的速度如此之快，以至于GC無法跟上進度。

盡管有缺點，但我還是提到了這種技術，因為它既易于使用，有時又是唯一的工具。這也是一個不錯的指標，長時間觀察時出了點問題。

3.使用內(nèi)存分析器檢測內(nèi)存泄漏

內(nèi)存分析器就像處理內(nèi)存泄漏的廚師刀。它是查找和修復它們的主要工具。盡管其他技術可能更易于使用或更便宜（探查器許可證價格昂貴），但最好精通至少一個內(nèi)存探查器以有效解決內(nèi)存泄漏問題。

.NET內(nèi)存分析器中的大人物 是：dotMemory，SciTech內(nèi)存分析器 和 ANTS Memory Profiler。如果您擁有Visual Studio Enterprise，則還有一個“免費”分析器。

所有內(nèi)存分析器都以類似的方式工作。您可以附加到正在運行的進程，也可以打開轉儲文件。探查器將為您的進程的當前內(nèi)存堆創(chuàng)建一個快照。您可以通過各種方式分析快照，例如，以下是當前快照中所有已分配對象的列表：

圖片

您可以看到每種類型分配了多少實例，它們占用了多少內(nèi)存以及GC Root的引用路徑。

GC根是GC無法釋放的對象，因此GC根引用所引用的所有內(nèi)容也無法釋放。當前活動線程的靜態(tài)對象和本地對象是GC根。在了解.NET中的垃圾收集中了解更多信息。

最快，最有用的性能分析技術是比較內(nèi)存應返回相同狀態(tài)的2個快照。在操作之前拍攝第一個快照，在操作之后拍攝另一個快照。確切的步驟是：

1.從應用程序中的某種空閑狀態(tài)開始。這可能是主菜單或類似的東西。2.通過附加到進程或保存轉儲，使用Memory Profiler拍攝快照。3.運行懷疑會導致內(nèi)存泄漏的操作。返回到空閑狀態(tài)。4.拍攝第二張快照。5.將這兩個快照與您的內(nèi)存分析器進行比較。6.研究新創(chuàng)建的實例，它們很可能是內(nèi)存泄漏。檢查“ GC根目錄的路徑”，并嘗試了解為什么未釋放這些對象。

這是一個很棒的視頻，其中在SciTech內(nèi)存分析器 中比較了2個快照，并發(fā)現(xiàn)了內(nèi)存泄漏：

4.使用“ Make Object ID”查找內(nèi)存泄漏

在上一篇文章5避免C＃.NET中的事件造成內(nèi)存泄漏的技術中，您應該知道^[3]?我展示了一種通過在類Finalizer中放置斷點來查找內(nèi)存泄漏的技術。在這里，我將向您展示一種類似的方法，該方法更易于使用，并且不需要更改代碼。這利用了調(diào)試器的Make Object ID功能和Instant Window。

假設您懷疑某個類存在內(nèi)存泄漏。換句話說，您懷疑在運行特定方案后，此類仍保持引用狀態(tài)，并且GC從未收集過此類。要確定GC是否真正收集了它，請按照下列步驟操作：

1.在創(chuàng)建類實例的地方放置一個斷點。2.將鼠標懸停在變量上以打開調(diào)試器的數(shù)據(jù)提示，然后右鍵單擊并使用Make Object ID。您可以在立即窗口$ 1中鍵入以查看是否正確創(chuàng)建了對象ID。3.完成本應從實例中釋放實例的方案。4.使用已知的魔術線強制進行GC收集

GC.Collect();??? GC.WaitForPendingFinalizers(); GC.Collect();

5. 原文中有兩端視頻，由于微信審核的緣故，無法上傳，有興趣的可以查看原文。

參考這個流程，您可以通過在立即窗口中鍵入魔術線來強制進行垃圾收集，從而使該技術成為完全的調(diào)試體驗，而無需更改代碼。

重要提示：這種做法在.NET Core 2.X調(diào)試器（問題^[4]）中不能很好地工作。強制在與對象分配相同的范圍內(nèi)進行垃圾回收不會釋放該對象。通過將另一種方法中的垃圾回收強制超出范圍，您可以花費更多的精力。

5.當心常見的內(nèi)存泄漏源

始終存在導致內(nèi)存泄漏的風險，但是某些模式更有可能造成內(nèi)存泄漏。我建議在使用這些工具時要格外小心，并使用最新的最佳做法等技術來主動檢查內(nèi)存泄漏。

以下是一些較常見的違規(guī)者：

?.NET中的事件因導致內(nèi)存泄漏而臭名昭著。您可以無辜地訂閱一個事件，甚至在不懷疑的情況下導致破壞性的內(nèi)存泄漏。這個主題是如此重要，以至于我專門寫了整篇文章：您應該知道的5種避免C＃.NET中的事件造成內(nèi)存泄漏的技術^[5]?特別是靜態(tài)變量，集合和靜態(tài)事件應該總是看起來可疑。請記住，所有靜態(tài)變量都是GC根，因此GC絕不會收集它們。?緩存功能 –任何類型的緩存機制都可以輕易導致內(nèi)存泄漏。通過最終將高速緩存信息存儲在內(nèi)存中，它將填滿并導致OutOfMemory異常。解決方案可以是定期刪除較早的緩存或限制緩存量。?WPF綁定可能很危險。經(jīng)驗法則是始終綁定到DependencyObject或一種 INotifyPropertyChanged 賓語。如果您這樣做失敗，WPF將從靜態(tài)變量創(chuàng)建對綁定源（即ViewModel）的強引用，從而導致內(nèi)存泄漏。此有用的StackOverflow線程中有關WPF綁定泄漏的更多信息?被捕獲的成員 –可能很明顯，事件處理程序方法意味著引用了一個對象，但是當變量在匿名方法中被捕獲時，也會被引用。這是內(nèi)存泄漏的示例：

public class MyClass { private int _wiFiChangesCounter = 0; public MyClass(WiFiManager wiFiManager) { wiFiManager.WiFiSignalChanged += (s, e) => _wiFiChangesCounter++; } }

?永不終止的線程 – 每個線程的活動堆棧都被視為GC根。這意味著在線程終止之前，GC不會收集其在堆棧上的變量的任何引用。這也包括計時器。如果您的Timer的滴答處理程序是一個方法，則該方法的對象被視為已引用，并且不會被收集。這是內(nèi)存泄漏的示例：

public class MyClass { public MyClass(WiFiManager wiFiManager) { Timer timer = new Timer(HandleTick); timer.Change(TimeSpan.FromSeconds(5), TimeSpan.FromSeconds(5)); }private void HandleTick(object state) { // do something } }

有關此主題的更多信息，請查看我的文章8 .NET中導致內(nèi)存泄漏的方法^[6]。

6.使用“處置”模式來防止非托管內(nèi)存泄漏

您的.NET應用程序不斷使用非托管資源。

.NET框架本身在很大程度上依賴于非托管代碼來進行內(nèi)部操作，優(yōu)化和Win32 API。

隨時使用Streams，Graphics或Files 對于 例如，您可能正在執(zhí)行非托管代碼。使用非托管代碼的.NET框架類通常實現(xiàn)IDisposable。那是因為非托管資源需要明確地釋放，這發(fā)生在Dispose方法中。您唯一的工作就是記住并調(diào)用Dispose方法。如果可能，請使用using語句。

public void Foo() {using (var stream = new FileStream(@"C:\Temp\SomeFile.txt",FileMode.OpenOrCreate)){// do stuff}// stream.Dispose() will be called even if an exception occurs }

在使用語句轉換的代碼放到一個嘗試/最后的場景，在后面聲明的Dispose方法被調(diào)用的最后方法。但是，即使您不調(diào)用Dispose方法，這些資源也將被釋放，因為.NET類使用Dispose Pattern^[7]。這基本上意味著，如果之前未調(diào)用Dispose，則在對象被垃圾回收時從Finalizer調(diào)用它。也就是說，如果您沒有內(nèi)存泄漏并且確實調(diào)用了終結器。

當您自己分配非托管資源時，則絕對應該使用Dispose模式。這是一個例子：

public?class?MyClass?:?IDisposable {private IntPtr _bufferPtr;public int BUFFER_SIZE = 1024 * 1024; // 1 MBprivate bool _disposed = false;public MyClass(){_bufferPtr = Marshal.AllocHGlobal(BUFFER_SIZE);}protected virtual void Dispose(bool disposing){if (_disposed)return;if (disposing){// Free any other managed objects here.}// Free any unmanaged objects here.Marshal.FreeHGlobal(_bufferPtr);_disposed = true;}public void Dispose(){Dispose(true);GC.SuppressFinalize(this);}~MyClass(){Dispose(false);} }

?這種模式的重點是允許顯式處置資源。還要增加一種保護措施，如果未調(diào)用Dispose（），則將在垃圾回收期間（在Finalizer中）處置您的資源。

該GC.SuppressFinalize（這）也很重要。如果該對象已經(jīng)存在，則可以確保終結器未在垃圾回收上被調(diào)用處置。使用終結器的對象將以不同的方式釋放，并且成本更高。將終結器添加到稱為F-Reachable-Queue的對象中，這使該對象在額外的GC生成后仍然存在。還有其他并發(fā)癥^[8]。

7.從代碼添加內(nèi)存遙測

有時，您可能想定期記錄您的內(nèi)存使用情況。也許您懷疑生產(chǎn)服務器存在內(nèi)存泄漏。當您的內(nèi)存達到一定限制時，您可能想采取一些措施。或者，也許您只是養(yǎng)成監(jiān)視內(nèi)存的好習慣。

我們可以從應用程序本身中獲取很多信息。使用當前的內(nèi)存很簡單：

Process currentProc = Process.GetCurrentProcess(); var bytesInUse = currentProc.PrivateMemorySize64;

有關更多信息，可以使用用于PerfMon的PerformanceCounter類：

PerformanceCounter ctr1 = new PerformanceCounter("Process", "Private Bytes", Process.GetCurrentProcess().ProcessName); PerformanceCounter ctr2 = new PerformanceCounter(".NET CLR Memory", "# Gen 0 Collections", Process.GetCurrentProcess().ProcessName); PerformanceCounter ctr3 = new PerformanceCounter(".NET CLR Memory", "# Gen 1 Collections", Process.GetCurrentProcess().ProcessName); PerformanceCounter ctr4 = new PerformanceCounter(".NET CLR Memory", "# Gen 2 Collections", Process.GetCurrentProcess().ProcessName); PerformanceCounter ctr5 = new PerformanceCounter(".NET CLR Memory", "Gen 0 heap size", Process.GetCurrentProcess().ProcessName); //... Debug.WriteLine("ctr1 = " + ctr1 .NextValue()); Debug.WriteLine("ctr2 = " + ctr2 .NextValue()); Debug.WriteLine("ctr3 = " + ctr3 .NextValue()); Debug.WriteLine("ctr4 = " + ctr4 .NextValue()); Debug.WriteLine("ctr5 = " + ctr5 .NextValue());

可從任何perfMon計數(shù)器獲得信息，這是很多信息。但是，您可以更深入。CLR MD（Microsoft.Diagnostics.Runtime）允許您檢查當前的內(nèi)存堆并獲取任何可能的信息。例如，您可以打印內(nèi)存中所有已分配的類型，包括實例計數(shù)，根目錄路徑等。您幾乎從代碼中獲得了一個內(nèi)存探查器。

要了解使用CLR MD可以實現(xiàn)的目標，請查看Dudi Keleti的DumpMiner。

所有這些信息都可以記錄到文件中，甚至更好地記錄到遙測工具（如Application Insights）中。

8.測試內(nèi)存泄漏

主動測試內(nèi)存泄漏是一個好習慣。這并不難。您可以使用以下簡短模式：

[Test] void MemoryLeakTest() { var weakRef = new WeakReference(leakyObject) // Ryn an operation with leakyObject GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); Assert.IsFalse(weakRef.IsAlive); }

為了進行更深入的測試，諸如SciTech的.NET Memory Profiler和dotMemory之類的內(nèi)存分析器提供了一個測試API：

MemAssertion.NoInstances(typeof(MyLeakyClass)); MemAssertion.NoNewInstances(typeof(MyLeakyClass), lastSnapshot); MemAssertion.MaxNewInstances(typeof(Bitmap), 10);

摘要

你的新年決心是怎樣的?我新年的決心是：更好的內(nèi)存管理。

我希望這篇文章能給您帶來一些價值，如果您訂閱^[9]我的博客或在下面發(fā)表評論，我將非常樂意。歡迎任何反饋。

References

[1]?難以利用:?https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019S9cSAE&l=en-IL
[2]?說明:?https://stackoverflow.com/a/1986486/1229063
[3]?5避免C＃.NET中的事件造成內(nèi)存泄漏的技術中，您應該知道:?https://michaelscodingspot.com/2018/12/14/5-techniques-to-avoid-memory-leaks-by-events-in-c-net-you-should-know/
[4]?問題:?https://github.com/dotnet/coreclr/issues/20156
[5]?您應該知道的5種避免C＃.NET中的事件造成內(nèi)存泄漏的技術:?https://michaelscodingspot.com/2018/12/14/5-techniques-to-avoid-memory-leaks-by-events-in-c-net-you-should-know/
[6]?8 .NET中導致內(nèi)存泄漏的方法:?https://michaelscodingspot.com/ways-to-cause-memory-leaks-in-dotnet/
[7]?Dispose Pattern:?https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-dispose
[8]?其他并發(fā)癥:?https://www.jetbrains.com/help/dotmemory/Analyzing_GC_Roots.html
[9]?訂閱:?https://michaelscodingspot.com/subscribe/

總結

以上是生活随笔為你收集整理的如何查找，修复和避免C＃.NET中内存泄漏的8个最佳实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。