經(jīng)常看到有群友調(diào)侃“為什么搞JAVA的總在學(xué)習(xí)JVM調(diào)優(yōu)？那是因?yàn)镴ava爛！我們.NET就不需要搞這些！”真的是這樣嗎？今天我就用一個案例來分析一下。
昨天，一位學(xué)生問了我一個問題：他建了一個默認(rèn)的ASP.NET Core Web API的項(xiàng)目，也就是那個WeatherForecast的默認(rèn)項(xiàng)目模板，然后他把默認(rèn)的生成5條數(shù)據(jù)的代碼，改成了生成150000條數(shù)據(jù)，其他代碼沒變，如下：
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個并發(fā)請求，發(fā)現(xiàn)內(nèi)存一路飆升到7GB，并且在壓力測試結(jié)束之后，內(nèi)存占用也不見回落。而他用Python/ target=_blank class=infotextkey>Python編寫的同樣功能的Web API項(xiàng)目，他用壓力測試工具對這個Python編寫的Web API模擬了同樣多的請求，發(fā)現(xiàn)內(nèi)存同樣飆升，但是在壓力測試結(jié)束之后，內(nèi)存占用很快回落到了正常的水平。
他不由得發(fā)出了疑問“這樣簡單的程序就有內(nèi)存泄漏了嗎？.NET的性能這么差嗎？”
我用了四種方式“解決”了他的這個問題，下面我將會依次分析這幾種方式的做法和原理。在這之前，我先簡單科普一下垃圾回收（GC）的基本原理：
一個被創(chuàng)建出來的對象是占據(jù)內(nèi)存的，我們必須在對象不再需要被使用之后把對象占據(jù)的內(nèi)存釋放出來，從而避免程序的內(nèi)存占用越來越高。在C語言中，需要程序員來使用malloc來進(jìn)行內(nèi)存的申請，然后使用free進(jìn)行內(nèi)存的釋放。而在C#、Java、Python等現(xiàn)代編程語言中，程序員很少需要去關(guān)心一個被創(chuàng)建出來的對象，程序員只需要根據(jù)需要盡情地new對象出來即可，垃圾回收器（Garbage Collector，簡稱GC）會幫我們把用不到的對象進(jìn)行回收。
關(guān)于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()轉(zhuǎn)換為數(shù)組再返回，因此我們把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)]
});
}
再運(yùn)行同樣的壓力測試，驚人的一幕發(fā)生了，峰值內(nèi)存占用也不到100MB。
原理分析：
這是為什么呢？IEnumerable以及LINQ默認(rèn)是以一種“流水線”的方式在工作，也就是說使用IEnumerable的消費(fèi)者（比如這里消費(fèi)IEnumerable的應(yīng)該是Json序列化器）每調(diào)用MoveNext()一次獲取一條數(shù)據(jù)才執(zhí)行一次Select()來創(chuàng)建一個新的WeatherForecast對象。而加上ToArray()之后，則是一次性生成150000個WeatherForecast對象，并且把這150000個對象放到一個數(shù)組中才把這個大數(shù)組返回。
對于不采用ToArray()的“流水線式”工作方式，對象是一個個產(chǎn)生、一個個的消費(fèi)，因此同時(shí)并發(fā)生成的對象是“緩緩流淌”地，因此不會有ToArray()那樣逐漸累積150000個對象的操作，因此并發(fā)內(nèi)存占用更小。同時(shí)，由于WeatherForecast對象是流水線式生產(chǎn)、消費(fèi)的，因此當(dāng)一個WeatherForecast對象被消費(fèi)完成后，就“可以”被GC回收了。而用ToArray()之后，數(shù)組對象會持有那150000個WeatherForecast對象的引用，因此只有數(shù)組對象被標(biāo)記為“可回收”之后，那150000個WeatherForecast對象才有可能被標(biāo)記為“可回收”，因此WeatherForecast對象被回收的機(jī)會被大大推后。
不知道為什么微軟官方要給WeatherForecast這個Web API例子項(xiàng)目代碼里給出ToArray()這樣沒必要的寫法，我要去找微軟的人去反饋，誰也別攔著我！
這給我們的啟示就是：盡量讓Linq“流水線式”工作，盡量使用IEnumerable類型，而不是數(shù)組或者List類型，每次對IEnumerable類型使用ToArray()、ToList()操作的時(shí)候要謹(jǐn)慎。
上面這個方案是最完美的方案，下面的幾種方案只是為了幫助大家更深入的理解GC。
解決方案二：把class改成struct
做法：仍然保留原始的ToArray()，但是把WeatherForecast類型從class改為struct（結(jié)構(gòu)體），代碼如下：
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; }
}
再運(yùn)行同樣的壓力測試，用struct的峰值內(nèi)存占用只有用class的大約一半，同樣的，在壓力測試結(jié)束之后，內(nèi)存占用沒有回落。
原理分析：class對象包含的信息更多，而struct包含的信息更少，而且struct的內(nèi)存結(jié)構(gòu)更加緊湊，因此包含同樣成員的struct比class對象內(nèi)存占用更小。這就是為什么把class改為struct之后，峰值內(nèi)存占用降低的原因。
有的朋友可能會問“不是說struct對象是分配在棧上，會用完了之后自動回收，不需要GC回收嗎？為什么在壓力測試結(jié)束后內(nèi)存占用沒有回落呢？難道struct的內(nèi)存沒有被自動回收嗎？”。需要注意的是“struct對象會自動回收，不需要GC”這種情況只發(fā)生在struct對象沒有被引用類型對象所引用的情況，一旦一個struct對象被一個引用類型對象引用之后，struct對象也需要由GC來回收。我們的代碼中由于進(jìn)行了ToArray()操作，所以這150000個struct對象會被一個數(shù)組引用，因此這些struct對象就必須依賴于GC的回收了。
解決方案三： 手動GC
做法：既然由于GC沒有及時(shí)執(zhí)行導(dǎo)致在壓力測試結(jié)束之后內(nèi)存居高不下，那么我們可以在壓力測試結(jié)束后手動調(diào)用GC，強(qiáng)制運(yùn)行垃圾回收。
我們再創(chuàng)建一個新的Controller，然后在Action中調(diào)用一下GC.Collect()來強(qiáng)制執(zhí)行內(nèi)存回收。代碼如下：
public class ValuesController : ControllerBase
{
[HttpGet(Name = "RunGC")]
public string RunGC()
{
GC.Collect();
return "ok";
}
}
我們再執(zhí)行壓力測試，在壓力測試完成后，很顯然內(nèi)存占用沒有回落。然后我們多請求幾次RunGC()，我們就能發(fā)現(xiàn)內(nèi)存占用回落到100多MB了。
原理分析：GC.Collect();就是強(qiáng)制執(zhí)行內(nèi)存回收，所以那些還沒有被回收的WeatherForecast對象就會被回收了。為什么要多次調(diào)用GC.Collect();才會讓內(nèi)存占用回落到初始狀態(tài)呢？那是因?yàn)閮?nèi)存回收是比較消耗CPU的操作，為了避免對程序性能造成影響，所以不會一次執(zhí)行垃圾回收的時(shí)候把所有用不到的對象一次性全部回收。
主要注意的是，手動調(diào)用GC.Collect()不是一個好的習(xí)慣，因?yàn)镚C會根據(jù)策略選擇合適的時(shí)機(jī)來執(zhí)行內(nèi)存回收，手動的執(zhí)行垃圾回收可能會造成程序的性能問題。如果需要手動GC.Collect()來降低讓程序內(nèi)存占用的達(dá)到你的期望的目的，要么是你的程序需要優(yōu)化，要么是你對程序的內(nèi)存占用的期望是錯誤的。什么叫“對程序的內(nèi)存占用的期望是錯誤的”呢？下面這個解決方案會提到。
解決方案四：調(diào)整GC的類型
做法：在ASP.NET Core項(xiàng)目文件（也就是csproj文件）中加入如下的配置：
<PropertyGroup>
<ServerGarbageCollection>false</ServerGarbageCollection>
</PropertyGroup>
再運(yùn)行同樣的壓力測試，壓力測試結(jié)束后，內(nèi)存占用很快就回落到初始的100多MB了。
原理分析：我們知道，我們開發(fā)的程序常用的有兩種類別：桌面程序（如WinForms、WPF）和服務(wù)器端程序（如ASP.NET Core）。
桌面程序一般不會獨(dú)占整個操作系統(tǒng)的內(nèi)存和CPU資源，因?yàn)椴僮飨到y(tǒng)上還有很多其他程序在運(yùn)行，因此桌面程序在內(nèi)存和CPU占用上比較保守。對于一個桌面程序，如果它內(nèi)存占用過多，我們會認(rèn)為它不好。
與之相反，服務(wù)器端程序通常是擁有整個服務(wù)器的內(nèi)存和CPU資源的（因?yàn)檎５南到y(tǒng)都會把數(shù)據(jù)庫、Web Server、redis等部署到不同的計(jì)算機(jī)中），所以充分利用內(nèi)存和CPU能夠提升網(wǎng)站程序的性能。這就是為什么Oracle數(shù)據(jù)庫默認(rèn)會占滿服務(wù)器的大部分內(nèi)存的原因，因?yàn)閮?nèi)存閑著也是閑著，不如用起來提高性能。對于一個網(wǎng)站程序，如果可以通過占盡可能多的內(nèi)存提升性能，但是它卻占很少的內(nèi)存，我們會認(rèn)為它對內(nèi)存利用不足，當(dāng)然這里指的不是濫用內(nèi)存。
對應(yīng)的，.NET的GC有Workstation和Server兩種模式。Workstation模式是為桌面程序準(zhǔn)備的，內(nèi)存占用偏保守，而Server模式是為服務(wù)器端程序準(zhǔn)備的，內(nèi)存占用上更激進(jìn)。我們知道垃圾回收比較消耗資源，對于服務(wù)器端程序來講，頻繁的GC會降低性能，因此Server模式下，只要還有足夠的可用內(nèi)存，.NET會盡量降低GC的頻率和范圍。而桌面程序?qū)C造成的性能影響容忍度高，而對內(nèi)存占用過多則容忍度低。因此Workstation模式下，GC會更高頻的運(yùn)行，從而保證程序內(nèi)存占用小；而Server模式下，只要還有足夠多的可用內(nèi)存，GC就盡量少運(yùn)行，運(yùn)行的時(shí)候也不會長時(shí)間的進(jìn)行大量對象的回收。當(dāng)然，這兩種模式還有很多其他的區(qū)別，詳細(xì)請查看微軟的文檔：
https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/workstation-server-gc?WT.mc_id=DT-MVP-5004444
ASP.NET Core程序默認(rèn)就是啟用的Server模式的GC，所以壓力測試結(jié)束后，內(nèi)存也沒有回落。而通過<ServerGarbageCollection>false</ServerGarbageCollection>禁用Server模式的GC之后，GC就變成了Workstation模式后，程序就會更激進(jìn)地回收內(nèi)存了。當(dāng)然把服務(wù)器端程序改為Workstation模式之后，程序的性能就會受影響，因此除非有充足的理由，否則不建議這樣做，畢竟對于服務(wù)器來講，內(nèi)存閑著就是一種浪費(fèi)。
除了GC的模式之外，.NET中也像Java的JVM中一樣可以設(shè)置堆內(nèi)存的大小、百分比等各種復(fù)雜的GC調(diào)優(yōu)參數(shù)，詳細(xì)請閱讀微軟的文檔
https://learn.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector?WT.mc_id=DT-MVP-5004444
總結(jié)：盡量使用LINQ的“流水線”操作，盡量避免對大數(shù)據(jù)量的數(shù)據(jù)源進(jìn)行ToArray()或者ToList()；避免手動GC；建立對程序內(nèi)存占用的正確期望，對于服務(wù)器端程序來講并不是內(nèi)存占用越低越好；用好GC的模式，從而滿足不同程序的性能和內(nèi)存占用的不同追求；可以通過GC的參數(shù)來對于程序的性能進(jìn)行更加個性化的設(shè)置。
歡迎閱讀我編寫的《ASP.NET Core技術(shù)內(nèi)幕與項(xiàng)目實(shí)戰(zhàn)》，這本書的宗旨就是“講微軟文檔中沒有的內(nèi)容，講原理、講實(shí)踐、講架構(gòu)”。
