經常看到有群友調侃“為什麼搞Java的總在學習JVM調優？那是因為Java爛！我們.NET就不需要搞這些！”真的是這樣嗎？今天我就用一個案例來分析一下。 昨天，一位學生問了我一個問題：他建了一個預設的ASP.NET Core Web API的項目，也就是那個WeatherForecast的預設項目模 ...
經常看到有群友調侃“為什麼搞Java的總在學習JVM調優？那是因為Java爛！我們.NET就不需要搞這些！”真的是這樣嗎？今天我就用一個案例來分析一下。
昨天，一位學生問了我一個問題：他建了一個預設的ASP.NET Core Web API的項目，也就是那個WeatherForecast的預設項目模板，然後他把預設的生成5條數據的代碼，改成了生成150000條數據，其他代碼沒變，如下：
public IEnumerable<WeatherForecast> Get() { return Enumerable.Range(1, 150000).Select(index => new WeatherForecast { Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)), TemperatureC = Random.Shared.Next(-20, 55), Summary = Summaries[Random.Shared.Next(Summaries.Length)] }) .ToArray(); }
然後他用壓力測試工具對這個.NET編寫的Web API模擬了1000個併發請求，發現記憶體一路飆升到7GB，並且在壓力測試結束之後，記憶體占用也不見回落。而他用Python編寫的同樣功能的Web API項目，他用壓力測試工具對這個Python編寫的Web API模擬了同樣多的請求，發現記憶體同樣飆升，但是在壓力測試結束之後，記憶體占用很快回落到了正常的水平。
他不由得發出了疑問“這樣簡單的程式就有記憶體泄漏了嗎？.NET的性能這麼差嗎？”
我用了四種方式“解決”了他的這個問題，下麵我將會依次分析這幾種方式的做法和原理。在這之前，我先簡單科普一下垃圾回收（GC）的基本原理：
一個被創建出來的對象是占據記憶體的，我們必須在對象不再需要被使用之後把對象占據的記憶體釋放出來，從而避免程式的記憶體占用越來越高。在C語言中，需要程式員來使用malloc來進行記憶體的申請，然後使用free進行記憶體的釋放。而在C#、Java、Python等現代編程語言中，程式員很少需要去關心一個被創建出來的對象，程式員只需要根據需要盡情地new對象出來即可，垃圾回收器（Garbage Collector，簡稱GC）會幫我們把用不到的對象進行回收。
關於GC還有“0代、1代”等問題，這些問題大家可以看如下.NET官方的資料：https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/?WT.mc_id=DT-MVP-5004444
下麵開始談這幾種“解決方案”。
解決方案一：去掉ToArray()
做法：Get方法的返回值就是IEnumerable<WeatherForecast>類型，而Select()方法的返回值也就是同樣的類型，所以完全沒必要再ToArray()轉換為數組再返回，因此我們把ToArray()去掉。代碼如下：
public IEnumerable<WeatherForecast> Get() { return Enumerable.Range(1, 150000).Select(index => new WeatherForecast { Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)), TemperatureC = Random.Shared.Next(-20, 55), Summary = Summaries[Random.Shared.Next(Summaries.Length)] }); }
再運行同樣的壓力測試，驚人的一幕發生了，峰值記憶體占用也不到100MB。
原理分析：
這是為什麼呢？IEnumerable以及LINQ預設是以一種“流水線”的方式在工作，也就是說使用IEnumerable的消費者（比如這裡消費IEnumerable的應該是Json序列化器）每調用MoveNext()一次獲取一條數據才執行一次Select()來創建一個新的WeatherForecast對象。而加上ToArray()之後，則是一次性生成150000個WeatherForecast對象，並且把這150000個對象放到一個數組中才把這個大數組返回。
對於不採用ToArray()的“流水線式”工作方式，對象是一個個產生、一個個的消費，因此同時併發生成的對象是“緩緩流淌”地，因此不會有ToArray()那樣逐漸累積150000個對象的操作，因此併發記憶體占用更小。同時，由於WeatherForecast對象是流水線式生產、消費的，因此當一個WeatherForecast對象被消費完成後，就“可以”被GC回收了。而用ToArray()之後，數組對象會持有那150000個WeatherForecast對象的引用，因此只有數組對象被標記為“可回收”之後，那150000個WeatherForecast對象才有可能被標記為“可回收”，因此WeatherForecast對象被回收的機會被大大推後。
不知道為什麼微軟官方要給WeatherForecast這個Web API例子項目代碼里給出ToArray()這樣沒必要的寫法，我要去找微軟的人去反饋，誰也別攔著我！
這給我們的啟示就是：儘量讓Linq“流水線式”工作，儘量使用IEnumerable類型，而不是數組或者List類型，每次對IEnumerable類型使用ToArray()、ToList()操作的時候要謹慎。
上面這個方案是最完美的方案，下麵的幾種方案只是為了幫助大家更深入的理解GC。
解決方案二：把class改成struct
做法：仍然保留原始的ToArray()，但是把WeatherForecast類型從class改為struct（結構體），代碼如下：
public struct WeatherForecast { public DateOnly Date { get; set; } public int TemperatureC { get; set; } public int TemperatureF => 32 + (int)(TemperatureC / 0.5556); public string? Summary { get; set; } }
再運行同樣的壓力測試，用struct的峰值記憶體占用只有用class的大約一半，同樣的，在壓力測試結束之後，記憶體占用沒有回落。
原理分析：class對象包含的信息更多，而struct包含的信息更少，而且struct的記憶體結構更加緊湊，因此包含同樣成員的struct比class對象記憶體占用更小。這就是為什麼把class改為struct之後，峰值記憶體占用降低的原因。
有的朋友可能會問“不是說struct對象是分配在棧上，會用完了之後自動回收，不需要GC回收嗎？為什麼在壓力測試結束後記憶體占用沒有回落呢？難道struct的記憶體沒有被自動回收嗎？”。需要註意的是“struct對象會自動回收，不需要GC”這種情況只發生在struct對象沒有被引用類型對象所引用的情況，一旦一個struct對象被一個引用類型對象引用之後，struct對象也需要由GC來回收。我們的代碼中由於進行了ToArray()操作，所以這150000個struct對象會被一個數組引用，因此這些struct對象就必須依賴於GC的回收了。
當然不要因為struct比class占記憶體小就濫用struct，和class相比，struct也有缺點，具體請自行搜索資料。
解決方案三： 手動GC
做法：既然由於GC沒有及時執行導致在壓力測試結束之後記憶體居高不下，那麼我們可以在壓力測試結束後手動調用GC，強制運行垃圾回收。
仍然保留原始的ToArray()。我們再創建一個新的Controller，然後在Action中調用一下GC.Collect()來強制執行記憶體回收。代碼如下：
public class ValuesController : ControllerBase { [HttpGet(Name = "RunGC")] public string RunGC() { GC.Collect(); return "ok"; } }
我們再執行壓力測試，在壓力測試完成後，很顯然記憶體占用沒有回落。然後我們多請求幾次RunGC()，我們就能發現記憶體占用回落到100多MB了。
原理分析：GC.Collect();就是強制執行記憶體回收，所以那些還沒有被回收的WeatherForecast對象就會被回收了。為什麼要多次調用GC.Collect();才會讓記憶體占用回落到初始狀態呢？那是因為記憶體回收是比較消耗CPU的操作，為了避免對程式性能造成影響，所以不會一次執行垃圾回收的時候把所有用不到的對象一次性全部回收。
主要註意的是，手動調用GC.Collect()不是一個好的習慣，因為GC會根據策略選擇合適的時機來執行記憶體回收，手動的執行垃圾回收可能會造成程式的性能問題。如果需要手動GC.Collect()來降低讓程式記憶體占用的達到你的期望的目的，要麼是你的程式需要優化，要麼是你對程式的記憶體占用的期望是錯誤的。什麼叫“對程式的記憶體占用的期望是錯誤的”呢？下麵這個解決方案會提到。
解決方案四：調整GC的類型
做法：仍然保留原始的ToArray()，然後在ASP.NET Core項目文件（也就是csproj文件）中加入如下的配置：
<PropertyGroup> <ServerGarbageCollection>false</ServerGarbageCollection> </PropertyGroup>
再運行同樣的壓力測試，壓力測試結束後，記憶體占用很快就回落到初始的100多MB了。
原理分析：我們知道，我們開發的程式常用的有兩種類別：桌面程式（如WinForms、WPF）和伺服器端程式（如ASP.NET Core）。
桌面程式一般不會獨占整個操作系統的記憶體和CPU資源，因為操作系統上還有很多其他程式在運行，因此桌面程式在記憶體和CPU占用上比較保守。對於一個桌面程式，如果它記憶體占用過多，我們會認為它不好。
與之相反，伺服器端程式通常是擁有整個伺服器的記憶體和CPU資源的（因為正常的系統都會把資料庫、Web Server、Redis等部署到不同的電腦中），所以充分利用記憶體和CPU能夠提升網站程式的性能。這就是為什麼Oracle資料庫預設會占滿伺服器的大部分記憶體的原因，因為記憶體閑著也是閑著，不如用起來提高性能。對於一個網站程式，如果可以通過占儘可能多的記憶體提升性能，但是它卻占很少的記憶體，我們會認為它對記憶體利用不足，當然這裡指的不是濫用記憶體。
對應的，.NET的GC有Workstation和Server兩種模式。Workstation模式是為桌面程式準備的，記憶體占用偏保守，而Server模式是為伺服器端程式準備的，記憶體占用上更激進。我們知道垃圾回收比較消耗資源，對於伺服器端程式來講，頻繁的GC會降低性能，因此Server模式下，只要還有足夠的可用記憶體，.NET會儘量降低GC的頻率和範圍。而桌面程式對GC造成的性能影響容忍度高，而對記憶體占用過多則容忍度低。因此Workstation模式下，GC會更高頻的運行，從而保證程式記憶體占用小；而Server模式下，只要還有足夠多的可用記憶體，GC就儘量少運行，運行的時候也不會長時間的進行大量對象的回收。當然，這兩種模式還有很多其他的區別，詳細請查看微軟的文檔： https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/workstation-server-gc?WT.mc_id=DT-MVP-5004444
ASP.NET Core程式預設就是啟用的Server模式的GC，所以壓力測試結束後，記憶體也沒有回落。而通過<ServerGarbageCollection>false</ServerGarbageCollection>禁用Server模式的GC之後，GC就變成了Workstation模式後，程式就會更激進地回收記憶體了。當然把伺服器端程式改為Workstation模式之後，程式的性能就會受影響，因此除非有充足的理由，否則不建議這樣做，畢竟對於伺服器來講，記憶體閑著就是一種浪費。
除了GC的模式之外，.NET中也像Java的JVM中一樣可以設置堆記憶體的大小、百分比等各種複雜的GC調優參數，詳細請閱讀微軟的文檔 https://learn.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector?WT.mc_id=DT-MVP-5004444
總結：儘量使用LINQ的“流水線”操作，儘量避免對大數據量的數據源進行ToArray()或者ToList()；避免手動GC；建立對程式記憶體占用的正確期望，對於伺服器端程式來講並不是記憶體占用越低越好；用好GC的模式，從而滿足不同程式的性能和記憶體占用的不同追求；可以通過GC的參數來對於程式的性能進行更加個性化的設置。
歡迎閱讀我編寫的《ASP.NET Core技術內幕與項目實戰》，這本書的宗旨就是“講微軟文檔中沒有的內容，講原理、講實踐、講架構”。具體見右邊公告。
