大型 .NET 應用程序中的內存問題是某種無聲的殺手。有點像高血壓。你可以長期吃垃圾食品而忽略它，直到有一天你面臨嚴重的問題。對于 .NET 程序，該嚴重問題可能是高內存消耗、主要性能問題和徹底崩潰。在這篇文章中，您將看到如何將我們的應用程序的血壓保持在健康水平。

你怎么知道你的內存使用情況是否健康？你需要做什么來保持它的健康？這正是本文要討論的內容。我們將介紹 6 種最佳做法，以保持內存健康并在出現問題時檢測問題。您還將看到優化垃圾收集并使您的應用程序非常快速的最佳實踐。

1. 應盡快收集對象

為了使您的程序快速運行，主要目標是盡快收集對象。要理解為什么它很重要，您需要了解 .NET 的分代垃圾收集器。當使用該new子句創建對象時，它們是在第 0 代的堆上創建的。那是內存中非常小的空間。如果在有 Gen 0 集合時它們仍然被引用，它們將被提升到 Gen 1。Gen 1 是更大的內存空間。如果它們在有第 1 代集合時仍被引用，則將它們提升到第 2 代。

Gen 0 集合是最頻繁的并且非常快。Gen 1 集合涵蓋 Gen 0 內存空間和 Gen 1 內存空間，并且它們更昂貴。Gen 2 集合包括整個內存空間，包括大對象堆 (LOH)。它們非常昂貴。GC 已優化為具有許多 Gen 0 集合、較少的 Gen 1 集合和很少的 Gen 2 集合。但是，如果您有許多對象被提升到更高代，那么您將產生相反的效果。這會導致內存壓力[1]（又名 GC 壓力）和性能不佳。

順便說一下，新對象的分配非常便宜。您唯一需要擔心的是集合。

那么如何在低代收集對象呢？很簡單，只需確保不會盡快引用它們即可。有些對象，比如單例，必須永遠在內存中。沒關系，它們通常是不會消耗大量內存的服務。

2. 使用緩存……但要小心

根據定義，像緩存這樣的機制很麻煩。這些是長期存在的臨時對象，可能會升級到第 2 代。雖然這對 GC 壓力不利，但通常值得付出代價，因為緩存確實可以幫助提高性能。但你必須密切關注它。

緩解部分內存壓力的一種方法是使用可變緩存對象。這意味著不是替換緩存對象，而是更新現有對象。這意味著 GC 提升對象和啟動更多 Gen 0 和 Gen 1 收集的工作更少。

這是一個例子。假設您正在緩存來自在線雜貨店的庫存商品。您有一個緩存機制來存儲經常查詢的項目的價格和數據。就像那些會導致高血壓的冷凍比薩餅。假設每 5 分鐘您必須使緩存無效并重新查詢數據庫，以防細節發生變化。因此，在這種情況下，不是創建新Pizza對象，而是更改現有對象的狀態。

3. 留意 GC 中的時間百分比

如果您想知道垃圾收集對執行時間的影響有多大，這很容易做到。簡單看看性能計數器.NET CLR Memory | % GC 時間。這將顯示垃圾收集器使用了百分之多少的執行時間。有許多工具可以查看性能計數器。在 windows 中，您可以使用 PerfMon。在 linux 中，您可以使用dotnet-trace[2]。要了解更多信息，請查看我的文章Use Performance Counters in .NET to measure Memory, CPU, and Everything[3]。

我將給您一些神奇的數字，但請注意這些數字，因為一切都有其自身的背景。對于大型應用程序，10% 的 GC 時間可能是一個健康的百分比。GC 中 20% 的時間處于臨界狀態，任何更多都意味著您有問題。

4. 留意那些 Gen 2 Collections

除了 GC 中的時間百分比，您應該監控的另一個重要指標是 Gen 2 收集的數量。或者更確切地說是第 2 代收藏的速度。目標是盡可能少地使用它們。考慮到這些是完整的內存堆集合。當 GC 收集所有內容時，它們有效地凍結了應用程序的所有線程。

對于您應該擁有多少 Gen 2 系列，我無法給出一個神奇的數字。但我建議每隔一段時間積極監控這個數字，如果比率上升，那么你可能會添加一些非常糟糕的行為。您可以通過性能計數器.NET CLR Memory |查看該數字。% Gen 2 集合

PerfMon 顯示第 2 代集合

5. 監控穩定的內存消耗

考慮應用程序的常規狀態。有些事情一直在發生。它可能是一個服務請求的服務器，一個從隊列中提取消息的服務，一個有很多屏幕的桌面應用程序。在此期間，您的應用程序不斷創建新對象，執行一些操作，然后釋放這些對象并返回到正常狀態。這意味著從長遠來看，內存消耗應該或多或少相同。當然，它可能會在高峰時間或繁重操作期間達到高水平，但一旦完成它應該會恢復正常。

但是，如果您監控了許多應用程序，您可能知道有時內存會隨著時間的推移而增加。內存的平均消費緩慢上升到更高的水平，即使它在邏輯上不應該。這種行為的原因幾乎總是內存泄漏[4]。這是一個對象不再使用的現象，但由于某種原因，它仍然被引用，因此從未被收集。

當一個操作導致對象泄漏時，每個這樣的操作都會消耗更多的內存。隨著時間的推移，記憶力上升。當足夠的時間過去時，內存接近其極限。在 32 位進程中，該限制為 4GB。在 64 位進程中，它取決于機器約束。當我們如此接近極限時，垃圾收集器就會恐慌。它開始為每個其他分配觸發全內存第 2 代收集，以免內存不足。這很容易使您的應用程序變慢。當更多的時間過去時，內存確實達到了它的極限，并且應用程序會因災難性的OutOfMemoryException. 你有它 - 相當于心臟病發作。

為了確保您不會達到這種狀態，我的建議是隨著時間的推移主動監控內存消耗。最好的方法是查看性能計數器Process | Private Bytes。您可以使用Process explorer[5]或 PerfMon輕松完成。

6. 定期查找內存泄漏

內存問題的#1 罪魁禍首毫無疑問是內存泄漏。很容易造成它們，它們可以被長期忽視，最終會造成大量損害。在應用程序持續崩潰的階段修復內存泄漏非常困難。您必須更改可能導致各種回歸錯誤的舊代碼。因此，我將為具有健康內存的應用程序添加第二個主要目標：修復并避免內存泄漏。

期望您的團隊永遠不會引入內存泄漏是不現實的。并且在每次新提交時檢查整個應用程序中的內存泄漏是不切實際的。相反，我建議添加每隔一段時間檢查內存泄漏的做法，它可能是每周、每月或每季度，具體取決于你的需求。

一種方法是在每次看到內存上升時檢查內存泄漏（如提示 #5 中建議的那樣）。但問題是內存占用低的泄漏也會導致很多問題。例如，您可能有一些本應收集但仍處于活動狀態的對象，并且仍有代碼在其中執行，這會導致不正確的行為。

檢測和修復內存泄漏的最佳方法是使用內存分析器。在我的文章Demystifying Memory Profilers in C# .NET Part 2: Memory Leaks 中[6]了解如何做到這一點。

要了解哪種設計會導致內存泄漏，請查看我的文章.NET 中可能導致內存泄漏的 8 種方式[7]。

總結

所以你有它，一個健康記憶狀態的秘訣。如果您遵循這些建議，您的應用程序將很快并且消耗很少的內存。但說真的，請吃健康的食物和鍛煉

References

[1] 內存壓力: https://michaelscodingspot.com/avoid-gc-pressure/[2] dotnet-trace: https://github.com/dotnet/diagnostics/blob/master/documentation/dotnet-trace-instructions.md[3] Use Performance Counters in .NET to measure Memory, CPU, and Everything: https://michaelscodingspot.com/performance-counters/[4] 內存泄漏: https://michaelscodingspot.com/ways-to-cause-memory-leaks-in-dotnet/[5] Process explorer: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer[6] Demystifying Memory Profilers in C# .NET Part 2: Memory Leaks 中: https://michaelscodingspot.com/memory-profilers-for-memory-leaks/[7] .NET 中可能導致內存泄漏的 8 種方式: https://michaelscodingspot.com/ways-to-cause-memory-leaks-in-dotnet/