內存分配概要
前段時間在園子里看到有人提到了GC學習的重要性，很贊同他的觀點。充分了解GC可以幫助我們更好的認識.NET的設計以及為何在雲原生開發中.NET Core會占有更大的優勢，這也是一個程序員成長到更高層次所需要經歷的過程。在認識GC的過程中，我們先看一下.NET中內存分配的概要知識。
.NET分配內存，主要依據托管資源和非托管資源進行分配。托管資源分配到了托管堆中並受CLR的管理，非托管資源分配到了非托管堆中。該節主要討論托管資源的分配。
CLR支持兩種基本類型：值類型和引用類型。CLR對這兩種類型在運行時有兩種分配方式：
內存的分配過程如下圖所示
需要注意的是，CLR還要維護一個指針，稱為NextObjPtr，這個指針指向下一個對象再堆中的分配位置。初始化時，NextObjPtr設為地址空間區域的基地址。一個區域被非垃圾對象填滿后，CLR會分配更多的區域，指針也會不斷偏移。new操作符會返回對象的引用，就在返回這個引用之前，NextObjPtr指針的值會加上對象占用的字節數來得到一個新值，即下一個對象放入托管堆時的地址。
垃圾回收算法與GC運行機制
常用的垃圾回收算法主要有引用計數算法和引用跟蹤算法。引用計算有着明顯的缺陷，.NET使用的垃圾回收算法是引用跟蹤法。小記：關於垃圾回收算法，我記得有一個知識點，在C#中如果出現了循環引用是否會導致內存溢出？如果比較了解這兩種算法就會知道不會溢出。
GC Root
引用跟蹤算法，通過一系列GCRoot對象作為起始點，從這些點開始向下搜索，搜索的路徑成為引用鏈，當一個對象到GC沒有任何引用鏈，說明對象可以被回收。
GC Root可以類比樹來解釋
GC根節點存在於堆棧中，指向Teacher引用對象。它包含一個ArrayList訂單集合，由Teacher對象引用。集合本身也包含對其元素的引用，隨着搜索深度的增加，樹也不斷長大。
GC根節點的引用源來自
(1)、堆棧
(2)、全局或靜態變量
(3)、CPU寄存器
(4)、互操作引用（COM / API調用中使用的.NET對象）
(5)、對象終結引用(objects finalization references)
GC運行機制
GC引入了代的概念，分為三種代，G0、G1、G2，G0對象生存周期較短，越往后生存周期越長(雖然G2中由於直接存儲了大對象，又由於G2不是每次都會掃描，所以大多數情況下，G2中的對象的生存周期比G0中的更長)。
GC運行如下圖所示
需要注意的是，CLR想要進行垃圾回收時，會立即掛起執行托管代碼中的所有線程，正在執行非托管代碼的線程不會掛起。所以再多線程環境下，可能會出現莫名其妙的詭異問題。
下圖為GC的整體運行流程，包含五個步驟：
垃圾回收時機與模式
CLR會在一下情況發生時，執行GC操作
1、當GC的代的預算大小已經達到閾值而無法對新對象分配空間的時候，比如GC的第0代已滿；
2、顯式調用System.GC.Collect()(顯示調用要慎重，因為手動調用可能會與自動執行的GC沖突，從而導致無法預知的問題)；
3、其他特殊情況，比如，操作系統內存不足、CLR卸載AppDomain、CLR關閉，甚至某些極端情況下系統參數設置改變也可能導致GC回收。
關於GC模式主要有
-
WorkStation GC
-
Server GC
-
Concurrent GC
-
Non-Concurrent GC
-
Background GC
詳細信息請參閱：https://www.cnblogs.com/dacc123/p/10980718.html，這篇文章關於GC模式的說明比較詳細。
.NET Core 3.0中的GC優化處理
.NET Core 3.0默認更好的支持Docker資源限制，官方團隊也在努力讓.NET Core成為真正的容器運行時，使其在低內存環境中具有容器感知功能並高效運行。
GC堆限制
.NET Core減少了CoreCLR默認使用的內存，如G0代內存分配預算，以更好地與現代處理器緩存大小和緩存層次結構保持一致。
在新的創建的GC堆數量的策略里，GC保留了一個內存片段，每個堆最小是16M，在低內存限制的機器上也可以很好的運行。在多核CPU的機器上運行時，系統並沒有設置CPU的核數限制。例如，如果在48核計算機上設置160 MB內存限制，則不需要創建48個GC堆。也就是說如果設置160 MB限制，則只會創建10個GC堆。如果未設置CPU限制，應用程序可以利用計算機上的所有核心。
有了這樣的新策略，可以不需要啟用Docker環境下的.NET Core應用的工作站GC的工作負載。
支持Docker內存限制
Docker資源限制建立在cgroup之上，而cgroup是Linux的內核功能。從運行時的角度來看，我們需要定位cgroup原語。
設置cgroup限制時的.NET Core 3.0內存使用規則：
- 默認GC堆大小：容器上cgroup內存限制的最大值
20MB或最大值的75% - 每個GC堆的最小保留段大小
16MB，這將減少在具有大量內核和小內存限制的計算機上創建的堆數
為了支持容器方案，添加了2個HardLimit配置：
- GCHeapHardLimit - 指定GC堆的硬限制
- GCHeapHardLimitPercent - 指定允許此進程使用的物理內存的百分比
如果同時指定了兩者，則首先檢查GCHeapHardLimit，並且只有在未指定GCHeapHardLimit時才檢查GCHeapHardLimitPercent。
如果兩者都未指定，但進程正在有內存限制的容器中運行，則默認是使用如下設置：
max（20mb，容器內存限制的75％）
如果指定了hardlimit配置，並且程序在有內存限制的容器中使用，GC堆的使用不會超過hardlimit限制，但總內存仍然受容器的內存限制。所以當我們統計內存消耗時，基於容器內存限制得出的數據。
舉例：
進程在設置了200MB限制的容器中運行，用戶還將GCHeapHardLimit配置為100MB。
如果把GC限制中100MB限制中的50MB用於GC，而容器限制中剩余的100MB用於其他用途，那么內存消耗即為(50+100)/200=75%。
GC將更積極地執行資源回收與釋放，因為GC堆越接近GCHeapHardLimit限制，就越能實現提供更多可用內存的目標，也越能使得應用程序可以繼續而又安全地運行。如果算法計算出的結果認為此時的GC效率低下，那么將避免持續執行完全阻塞的GC。
即使GC堆完全壓縮，GC依然會拋出一個OutOfMemoryException異常出來，這是因為所分配的堆大小超過了GCHeapHardLimit的限制。
由此可見，.NET Core 3.0的設計是要穩定運行於有資源限制的容器中。
支持DockerCPU限制
在CPU限制的情況下，Docker上設置的值將向上舍入為下一個整數值。此值是CoreCLR使用的最大有效CPU核數。
默認情況下，ASP.NET Core應用程序啟用了服務器GC（它不適用於控制台應用程序），因為它可以實現高吞吐量並減少跨核心的爭用。當進程僅限於單個處理器時，運行時會自動切換到工作站GC。即使您明確指定使用服務器GC，工作站GC也將始終用於單核環境。
通過計算CPU繁忙時間，設置CPU限制，我們避免了線程池的各種推導性競爭：
- 嘗試分配更多的線程以增加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