經常看到有群友調侃“為什麼搞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技術內幕與專案實戰》，這本書的宗旨就是“講微軟文件中沒有的內容，講原理、講實踐、講架構”。具體見右邊公告。