內(nèi)存分配概要

前段時間在園子里看到有人提到了GC學(xué)習(xí)的重要性，很贊同他的觀點。充分了解GC可以幫助我們更好的認(rèn)識.NET的設(shè)計以及為何在云原生開發(fā)中.NET Core會占有更大的優(yōu)勢，這也是一個程序員成長到更高層次所需要經(jīng)歷的過程。在認(rèn)識GC的過程中，我們先看一下.NET中內(nèi)存分配的概要知識。
.NET分配內(nèi)存，主要依據(jù)托管資源和非托管資源進(jìn)行分配。托管資源分配到了托管堆中并受CLR的管理，非托管資源分配到了非托管堆中。該節(jié)主要討論托管資源的分配。
CLR支持兩種基本類型：值類型和引用類型。CLR對這兩種類型在運行時有兩種分配方式：

內(nèi)存的分配過程如下圖所示

需要注意的是，CLR還要維護(hù)一個指針，稱為NextObjPtr，這個指針指向下一個對象再堆中的分配位置。初始化時，NextObjPtr設(shè)為地址空間區(qū)域的基地址。一個區(qū)域被非垃圾對象填滿后，CLR會分配更多的區(qū)域，指針也會不斷偏移。new操作符會返回對象的引用，就在返回這個引用之前，NextObjPtr指針的值會加上對象占用的字節(jié)數(shù)來得到一個新值，即下一個對象放入托管堆時的地址。

垃圾回收算法與GC運行機制

常用的垃圾回收算法主要有引用計數(shù)算法和引用跟蹤算法。引用計算有著明顯的缺陷，.NET使用的垃圾回收算法是引用跟蹤法。小記：關(guān)于垃圾回收算法，我記得有一個知識點，在C#中如果出現(xiàn)了循環(huán)引用是否會導(dǎo)致內(nèi)存溢出？如果比較了解這兩種算法就會知道不會溢出。

GC Root

引用跟蹤算法，通過一系列GCRoot對象作為起始點，從這些點開始向下搜索，搜索的路徑成為引用鏈，當(dāng)一個對象到GC沒有任何引用鏈，說明對象可以被回收。

GC Root可以類比樹來解釋

GC根節(jié)點存在于堆棧中，指向Teacher引用對象。它包含一個ArrayList訂單集合，由Teacher對象引用。集合本身也包含對其元素的引用，隨著搜索深度的增加，樹也不斷長大。

GC根節(jié)點的引用源來自

(1)、堆棧
(2)、全局或靜態(tài)變量
(3)、CPU寄存器
(4)、互操作引用（COM / API調(diào)用中使用的.NET對象）
(5)、對象終結(jié)引用(objects finalization references)

GC運行機制

GC引入了代的概念，分為三種代，G0、G1、G2，G0對象生存周期較短，越往后生存周期越長(雖然G2中由于直接存儲了大對象，又由于G2不是每次都會掃描，所以大多數(shù)情況下，G2中的對象的生存周期比G0中的更長)。

GC運行如下圖所示

需要注意的是，CLR想要進(jìn)行垃圾回收時，會立即掛起執(zhí)行托管代碼中的所有線程，正在執(zhí)行非托管代碼的線程不會掛起。所以再多線程環(huán)境下，可能會出現(xiàn)莫名其妙的詭異問題。

下圖為GC的整體運行流程，包含五個步驟：

垃圾回收時機與模式

CLR會在一下情況發(fā)生時，執(zhí)行GC操作

????? 1、當(dāng)GC的代的預(yù)算大小已經(jīng)達(dá)到閾值而無法對新對象分配空間的時候，比如GC的第0代已滿；

　　2、顯式調(diào)用System.GC.Collect()(顯示調(diào)用要慎重，因為手動調(diào)用可能會與自動執(zhí)行的GC沖突，從而導(dǎo)致無法預(yù)知的問題)；

　　3、其他特殊情況，比如，操作系統(tǒng)內(nèi)存不足、CLR卸載AppDomain、CLR關(guān)閉，甚至某些極端情況下系統(tǒng)參數(shù)設(shè)置改變也可能導(dǎo)致GC回收。

關(guān)于GC模式主要有

• WorkStation GC

• Server GC

• Concurrent GC

• Non-Concurrent GC

• Background GC

詳細(xì)信息請參閱：https://www.cnblogs.com/dacc123/p/10980718.html，這篇文章關(guān)于GC模式的說明比較詳細(xì)。

.NET Core 3.0的GC處理

.NET Core 3.0默認(rèn)更好的支持Docker資源限制，官方團(tuán)隊也在努力讓.NET Core成為真正的容器運行時，使其在低內(nèi)存環(huán)境中具有容器感知功能并高效運行。

GC堆限制

.NET Core減少了CoreCLR默認(rèn)使用的內(nèi)存，如G0代內(nèi)存分配預(yù)算，以更好地與現(xiàn)代處理器緩存大小和緩存層次結(jié)構(gòu)保持一致。

在新的創(chuàng)建的GC堆數(shù)量的策略里，GC保留了一個內(nèi)存片段，每個堆最小是16M，在低內(nèi)存限制的機器上也可以很好的運行。在多核CPU的機器上運行時，系統(tǒng)并沒有設(shè)置CPU的核數(shù)限制。例如，如果在48核計算機上設(shè)置160 MB內(nèi)存限制，則不需要創(chuàng)建48個GC堆。也就是說如果設(shè)置160 MB限制，則只會創(chuàng)建10個GC堆。如果未設(shè)置CPU限制，應(yīng)用程序可以利用計算機上的所有核心。

有了這樣的新策略，可以不需要啟用Docker環(huán)境下的.NET Core應(yīng)用的工作站GC的工作負(fù)載。

支持Docker內(nèi)存限制

Docker資源限制建立在cgroup之上，而cgroup是Linux的內(nèi)核功能。從運行時的角度來看，我們需要定位cgroup原語。

設(shè)置cgroup限制時的.NET Core 3.0內(nèi)存使用規(guī)則：

• 默認(rèn)GC堆大小：容器上cgroup內(nèi)存限制的最大值20MB或最大值的75%

• 每個GC堆的最小保留段大小16MB，這將減少在具有大量內(nèi)核和小內(nèi)存限制的計算機上創(chuàng)建的堆數(shù)

為了支持容器方案，添加了2個HardLimit配置：

• GCHeapHardLimit - 指定GC堆的硬限制

• GCHeapHardLimitPercent - 指定允許此進(jìn)程使用的物理內(nèi)存的百分比

如果同時指定了兩者，則首先檢查GCHeapHardLimit，并且只有在未指定GCHeapHardLimit時才檢查GCHeapHardLimitPercent。

如果兩者都未指定，但進(jìn)程正在有內(nèi)存限制的容器中運行，則默認(rèn)是使用如下設(shè)置：

max（20mb，容器內(nèi)存限制的75％）

如果指定了hardlimit配置，并且程序在有內(nèi)存限制的容器中使用，GC堆的使用不會超過hardlimit限制，但總內(nèi)存仍然受容器的內(nèi)存限制。所以當(dāng)我們統(tǒng)計內(nèi)存消耗時，基于容器內(nèi)存限制得出的數(shù)據(jù)。

舉例：

進(jìn)程在設(shè)置了200MB限制的容器中運行，用戶還將GCHeapHardLimit配置為100MB。

如果把GC限制中100MB限制中的50MB用于GC，而容器限制中剩余的100MB用于其他用途，那么內(nèi)存消耗即為(50+100)/200=75%。

GC將更積極地執(zhí)行資源回收與釋放，因為GC堆越接近GCHeapHardLimit限制，就越能實現(xiàn)提供更多可用內(nèi)存的目標(biāo)，也越能使得應(yīng)用程序可以繼續(xù)而又安全地運行。如果算法計算出的結(jié)果認(rèn)為此時的GC效率低下，那么將避免持續(xù)執(zhí)行完全阻塞的GC。

即使GC堆完全壓縮，GC依然會拋出一個OutOfMemoryException異常出來，這是因為所分配的堆大小超過了GCHeapHardLimit的限制。

由此可見，.NET Core 3.0的設(shè)計是要穩(wěn)定運行于有資源限制的容器中。

支持DockerCPU限制

在CPU限制的情況下，Docker上設(shè)置的值將向上舍入為下一個整數(shù)值。此值是CoreCLR使用的最大有效CPU核數(shù)。

默認(rèn)情況下，ASP.NET Core應(yīng)用程序啟用了服務(wù)器GC（它不適用于控制臺應(yīng)用程序），因為它可以實現(xiàn)高吞吐量并減少跨核心的爭用。當(dāng)進(jìn)程僅限于單個處理器時，運行時會自動切換到工作站GC。即使您明確指定使用服務(wù)器GC，工作站GC也將始終用于單核環(huán)境。

通過計算CPU繁忙時間，設(shè)置CPU限制，我們避免了線程池的各種推導(dǎo)性競爭：

• 嘗試分配更多的線程以增加CPU繁忙時間

• 嘗試分配更少的線程，因為添加更多的線程不會提高吞吐量

參考資料：

https://devblogs.microsoft.com/dotnet/using-net-and-docker-together-dockercon-2019-update/

https://github.com/dotnet/designs/blob/master/accepted/support-for-memory-limits.md

https://www.cnblogs.com/dacc123/p/10980718.html

https://blog.csdn.net/koudaidai/article/details/7794793

總結(jié)

以上是生活随笔為你收集整理的从CLR GC到CoreCLR GC看.NET Core为云而生的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。