目錄

• 解決方案一：去掉ToArray()
• 解決方案二：把class改成struct
• 解決方案三： 手動(dòng)GC
• 解決方案四：調(diào)整GC的類型

經(jīng)常看到有群友調(diào)侃“為什么搞Java的總在學(xué)習(xí)JVM調(diào)優(yōu)？那是因?yàn)镴ava爛！我們.NET就不需要搞這些！”真的是這樣嗎？今天我就用一個(gè)案例來(lái)分析一下。

昨天，一位學(xué)生問(wèn)了我一個(gè)問(wèn)題：他建了一個(gè)默認(rèn)的ASP.NET Core Web API的項(xiàng)目，也就是那個(gè)WeatherForecast的默認(rèn)項(xiàng)目模板，然后他把默認(rèn)的生成5條數(shù)據(jù)的代碼，改成了生成150000條數(shù)據(jù)，其他代碼沒(méi)變，如下：

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();

}

然后他用壓力測(cè)試工具對(duì)這個(gè).NET編寫的Web API模擬了1000個(gè)并發(fā)請(qǐng)求，發(fā)現(xiàn)內(nèi)存一路飆升到7GB，并且在壓力測(cè)試結(jié)束之后，內(nèi)存占用也不見(jiàn)回落。而他用Python編寫的同樣功能的Web API項(xiàng)目，他用壓力測(cè)試工具對(duì)這個(gè)Python編寫的Web API模擬了同樣多的請(qǐng)求，發(fā)現(xiàn)內(nèi)存同樣飆升，但是在壓力測(cè)試結(jié)束之后，內(nèi)存占用很快回落到了正常的水平。

他不由得發(fā)出了疑問(wèn)“這樣簡(jiǎn)單的程序就有內(nèi)存泄漏了嗎？.NET的性能這么差嗎？”

我用了四種方式“解決”了他的這個(gè)問(wèn)題，下面我將會(huì)依次分析這幾種方式的做法和原理。在這之前，我先簡(jiǎn)單科普一下垃圾回收（GC）的基本原理：

一個(gè)被創(chuàng)建出來(lái)的對(duì)象是占據(jù)內(nèi)存的，我們必須在對(duì)象不再需要被使用之后把對(duì)象占據(jù)的內(nèi)存釋放出來(lái)，從而避免程序的內(nèi)存占用越來(lái)越高。在C語(yǔ)言中，需要程序員來(lái)使用malloc來(lái)進(jìn)行內(nèi)存的申請(qǐng)，然后使用free進(jìn)行內(nèi)存的釋放。而在C#、Java、Python等現(xiàn)代編程語(yǔ)言中，程序員很少需要去關(guān)心一個(gè)被創(chuàng)建出來(lái)的對(duì)象，程序員只需要根據(jù)需要盡情地new對(duì)象出來(lái)即可，垃圾回收器（Garbage Collector，簡(jiǎn)稱GC）會(huì)幫我們把用不到的對(duì)象進(jìn)行回收。

關(guān)于GC還有“0代、1代”等問(wèn)題，這些問(wèn)題大家可以看如下.NET官方的資料：https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/?WT.mc_id=DT-MVP-5004444

下面開(kāi)始談這幾種“解決方案”。

解決方案一：去掉ToArray()

做法：Get方法的返回值就是IEnumerable<WeatherForecast>類型，而Select()方法的返回值也就是同樣的類型，所以完全沒(méi)必要再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)行同樣的壓力測(cè)試，驚人的一幕發(fā)生了，峰值內(nèi)存占用也不到100MB。

原理分析：

這是為什么呢？IEnumerable以及LINQ默認(rèn)是以一種“流水線”的方式在工作，也就是說(shuō)使用IEnumerable的消費(fèi)者（比如這里消費(fèi)IEnumerable的應(yīng)該是Json序列化器）每調(diào)用MoveNext()一次獲取一條數(shù)據(jù)才執(zhí)行一次Select()來(lái)創(chuàng)建一個(gè)新的WeatherForecast對(duì)象。而加上ToArray()之后，則是一次性生成150000個(gè)WeatherForecast對(duì)象，并且把這150000個(gè)對(duì)象放到一個(gè)數(shù)組中才把這個(gè)大數(shù)組返回。

對(duì)于不采用ToArray()的“流水線式”工作方式，對(duì)象是一個(gè)個(gè)產(chǎn)生、一個(gè)個(gè)的消費(fèi)，因此同時(shí)并發(fā)生成的對(duì)象是“緩緩流淌”地，因此不會(huì)有ToArray()那樣逐漸累積150000個(gè)對(duì)象的操作，因此并發(fā)內(nèi)存占用更小。同時(shí)，由于WeatherForecast對(duì)象是流水線式生產(chǎn)、消費(fèi)的，因此當(dāng)一個(gè)WeatherForecast對(duì)象被消費(fèi)完成后，就“可以”被GC回收了。而用ToArray()之后，數(shù)組對(duì)象會(huì)持有那150000個(gè)WeatherForecast對(duì)象的引用，因此只有數(shù)組對(duì)象被標(biāo)記為“可回收”之后，那150000個(gè)WeatherForecast對(duì)象才有可能被標(biāo)記為“可回收”，因此WeatherForecast對(duì)象被回收的機(jī)會(huì)被大大推后。

不知道為什么微軟官方要給WeatherForecast這個(gè)Web API例子項(xiàng)目代碼里給出ToArray()這樣沒(méi)必要的寫法，我要去找微軟的人去反饋，誰(shuí)也別攔著我！

這給我們的啟示就是：盡量讓Linq“流水線式”工作，盡量使用IEnumerable類型，而不是數(shù)組或者List類型，每次對(duì)IEnumerable類型使用ToArray()、ToList()操作的時(shí)候要謹(jǐn)慎。

上面這個(gè)方案是最完美的方案，下面的幾種方案只是為了幫助大家更深入的理解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)行同樣的壓力測(cè)試，用struct的峰值內(nèi)存占用只有用class的大約一半，同樣的，在壓力測(cè)試結(jié)束之后，內(nèi)存占用沒(méi)有回落。

原理分析：class對(duì)象包含的信息更多，而struct包含的信息更少，而且struct的內(nèi)存結(jié)構(gòu)更加緊湊，因此包含同樣成員的struct比class對(duì)象內(nèi)存占用更小。這就是為什么把class改為struct之后，峰值內(nèi)存占用降低的原因。

有的朋友可能會(huì)問(wèn)“不是說(shuō)struct對(duì)象是分配在棧上，會(huì)用完了之后自動(dòng)回收，不需要GC回收嗎？為什么在壓力測(cè)試結(jié)束后內(nèi)存占用沒(méi)有回落呢？難道struct的內(nèi)存沒(méi)有被自動(dòng)回收嗎？”。需要注意的是“struct對(duì)象會(huì)自動(dòng)回收，不需要GC”這種情況只發(fā)生在struct對(duì)象沒(méi)有被引用類型對(duì)象所引用的情況，一旦一個(gè)struct對(duì)象被一個(gè)引用類型對(duì)象引用之后，struct對(duì)象也需要由GC來(lái)回收。我們的代碼中由于進(jìn)行了ToArray()操作，所以這150000個(gè)struct對(duì)象會(huì)被一個(gè)數(shù)組引用，因此這些struct對(duì)象就必須依賴于GC的回收了。

當(dāng)然不要因?yàn)閟truct比class占內(nèi)存小就濫用struct，和class相比，struct也有缺點(diǎn)，具體請(qǐng)自行搜索資料。

解決方案三： 手動(dòng)GC

做法：既然由于GC沒(méi)有及時(shí)執(zhí)行導(dǎo)致在壓力測(cè)試結(jié)束之后內(nèi)存居高不下，那么我們可以在壓力測(cè)試結(jié)束后手動(dòng)調(diào)用GC，強(qiáng)制運(yùn)行垃圾回收。

仍然保留原始的ToArray()。我們?cè)賱?chuàng)建一個(gè)新的Controller，然后在Action中調(diào)用一下GC.Collect()來(lái)強(qiáng)制執(zhí)行內(nèi)存回收。代碼如下：

public class ValuesController : ControllerBase

{

    [HttpGet(Name = "RunGC")]

    public string RunGC()

    {

GC.Collect();

return "ok";

    }

}

我們?cè)賵?zhí)行壓力測(cè)試，在壓力測(cè)試完成后，很顯然內(nèi)存占用沒(méi)有回落。然后我們多請(qǐng)求幾次RunGC()，我們就能發(fā)現(xiàn)內(nèi)存占用回落到100多MB了。

原理分析：GC.Collect();就是強(qiáng)制執(zhí)行內(nèi)存回收，所以那些還沒(méi)有被回收的WeatherForecast對(duì)象就會(huì)被回收了。為什么要多次調(diào)用GC.Collect();才會(huì)讓內(nèi)存占用回落到初始狀態(tài)呢？那是因?yàn)閮?nèi)存回收是比較消耗CPU的操作，為了避免對(duì)程序性能造成影響，所以不會(huì)一次執(zhí)行垃圾回收的時(shí)候把所有用不到的對(duì)象一次性全部回收。

主要注意的是，手動(dòng)調(diào)用GC.Collect()不是一個(gè)好的習(xí)慣，因?yàn)镚C會(huì)根據(jù)策略選擇合適的時(shí)機(jī)來(lái)執(zhí)行內(nèi)存回收，手動(dòng)的執(zhí)行垃圾回收可能會(huì)造成程序的性能問(wèn)題。如果需要手動(dòng)GC.Collect()來(lái)降低讓程序內(nèi)存占用的達(dá)到你的期望的目的，要么是你的程序需要優(yōu)化，要么是你對(duì)程序的內(nèi)存占用的期望是錯(cuò)誤的。什么叫“對(duì)程序的內(nèi)存占用的期望是錯(cuò)誤的”呢？下面這個(gè)解決方案會(huì)提到。

解決方案四：調(diào)整GC的類型

做法：仍然保留原始的ToArray()，然后在ASP.NET Core項(xiàng)目文件（也就是csproj文件）中加入如下的配置：

<PropertyGroup>

    <ServerGarbageCollection>false</ServerGarbageCollection>

</PropertyGroup>

再運(yùn)行同樣的壓力測(cè)試，壓力測(cè)試結(jié)束后，內(nèi)存占用很快就回落到初始的100多MB了。

原理分析：我們知道，我們開(kāi)發(fā)的程序常用的有兩種類別：桌面程序（如WinForms、WPF）和服務(wù)器端程序（如ASP.NET Core）。

桌面程序一般不會(huì)獨(dú)占整個(gè)操作系統(tǒng)的內(nèi)存和CPU資源，因?yàn)椴僮飨到y(tǒng)上還有很多其他程序在運(yùn)行，因此桌面程序在內(nèi)存和CPU占用上比較保守。對(duì)于一個(gè)桌面程序，如果它內(nèi)存占用過(guò)多，我們會(huì)認(rèn)為它不好。

與之相反，服務(wù)器端程序通常是擁有整個(gè)服務(wù)器的內(nèi)存和CPU資源的（因?yàn)檎５南到y(tǒng)都會(huì)把數(shù)據(jù)庫(kù)、Web Server、Redis等部署到不同的計(jì)算機(jī)中），所以充分利用內(nèi)存和CPU能夠提升網(wǎng)站程序的性能。這就是為什么Oracle數(shù)據(jù)庫(kù)默認(rèn)會(huì)占滿服務(wù)器的大部分內(nèi)存的原因，因?yàn)閮?nèi)存閑著也是閑著，不如用起來(lái)提高性能。對(duì)于一個(gè)網(wǎng)站程序，如果可以通過(guò)占盡可能多的內(nèi)存提升性能，但是它卻占很少的內(nèi)存，我們會(huì)認(rèn)為它對(duì)內(nèi)存利用不足，當(dāng)然這里指的不是濫用內(nèi)存。

對(duì)應(yīng)的，.NET的GC有Workstation和Server兩種模式。Workstation模式是為桌面程序準(zhǔn)備的，內(nèi)存占用偏保守，而Server模式是為服務(wù)器端程序準(zhǔn)備的，內(nèi)存占用上更激進(jìn)。我們知道垃圾回收比較消耗資源，對(duì)于服務(wù)器端程序來(lái)講，頻繁的GC會(huì)降低性能，因此Server模式下，只要還有足夠的可用內(nèi)存，.NET會(huì)盡量降低GC的頻率和范圍。而桌面程序?qū)C造成的性能影響容忍度高，而對(duì)內(nèi)存占用過(guò)多則容忍度低。因此Workstation模式下，GC會(huì)更高頻的運(yùn)行，從而保證程序內(nèi)存占用小；而Server模式下，只要還有足夠多的可用內(nèi)存，GC就盡量少運(yùn)行，運(yùn)行的時(shí)候也不會(huì)長(zhǎng)時(shí)間的進(jìn)行大量對(duì)象的回收。當(dāng)然，這兩種模式還有很多其他的區(qū)別，詳細(xì)請(qǐng)查看微軟的文檔： 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，所以壓力測(cè)試結(jié)束后，內(nèi)存也沒(méi)有回落。而通過(guò)<ServerGarbageCollection>false</ServerGarbageCollection>禁用Server模式的GC之后，GC就變成了Workstation模式后，程序就會(huì)更激進(jìn)地回收內(nèi)存了。當(dāng)然把服務(wù)器端程序改為Workstation模式之后，程序的性能就會(huì)受影響，因此除非有充足的理由，否則不建議這樣做，畢竟對(duì)于服務(wù)器來(lái)講，內(nèi)存閑著就是一種浪費(fèi)。

除了GC的模式之外，.NET中也像Java的JVM中一樣可以設(shè)置堆內(nèi)存的大小、百分比等各種復(fù)雜的GC調(diào)優(yōu)參數(shù)，詳細(xì)請(qǐng)閱讀微軟的文檔 https://learn.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector?WT.mc_id=DT-MVP-5004444

總結(jié)：盡量使用LINQ的“流水線”操作，盡量避免對(duì)大數(shù)據(jù)量的數(shù)據(jù)源進(jìn)行ToArray()或者ToList()；避免手動(dòng)GC；建立對(duì)程序內(nèi)存占用的正確期望，對(duì)于服務(wù)器端程序來(lái)講并不是內(nèi)存占用越低越好；用好GC的模式，從而滿足不同程序的性能和內(nèi)存占用的不同追求；可以通過(guò)GC的參數(shù)來(lái)對(duì)于程序的性能進(jìn)行更加個(gè)性化的設(shè)置。

到此這篇關(guān)于.NET一行代碼實(shí)現(xiàn)GC調(diào)優(yōu)，讓程序不再占用內(nèi)存的文章就介紹到這了,更多相關(guān).NET一行代碼實(shí)現(xiàn)GC調(diào)優(yōu)內(nèi)容請(qǐng)搜索以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持！