首頁  >  文章  >  後端開發  >  解析.NET垃圾回收(GC)原理

解析.NET垃圾回收(GC)原理

怪我咯
怪我咯原創
2017-04-05 13:33:441471瀏覽

作為.NET進階內容的一部分,垃圾回收器(簡稱GC)是必須了解的內容。本著「簡單易懂」的原則,本文將說明CLR中垃圾回收器的工作原理。

基礎

託管堆(Managed Heap)

先來看MSDN的解釋:初始化新進程時,執行時會為進程保留一個連續的位址空間區域。這個保留的位址空間稱為託管堆。

“託管堆也是堆”,為什麼這樣說呢?這麼說是希望大家不要被「術語」迷惑,這個知識點的前提是「值類型和引用類型的區別」。這裡假設讀者已經知道「值型別儲存在堆疊中,參考型別儲存在堆中。(引用型別的參考儲存在堆疊中)」這個重要概念。所以,根據這個理論,除值類型外,CLR要求所有資源都從託管堆分配。

託管堆維護著一個指針,這裡命名為NextObjPtr,它指向下一個物件在堆中的分配位置。

CPU暫存器(CPU Register)

這個是電腦基礎知識,這裡複習一下,有助於對下面「根」概念的理解。

CPU暫存器是CPU自己的”暫存器”,比記憶體的存取還快。按與CPU遠近來分,離得最近的是暫存器,然後快取(電腦一、二、三級快取),最後記憶體。

根(Roots)

類別中定義的任何靜態字段,方法的參數,局部變數(僅限引用類型變數)等都是根,另外cpu暫存器中的物件指標也是根。根是CLR在堆之外可以找到的各種入口點。

物件可達與不可達(Objects reachable and unreachable)

如果一個根引用了堆中的一個對象,則該物件為「可達”,否則即是“不可達”。

垃圾回收的原因

從電腦組成的角度來講,所有的程式都是要駐留在記憶體中運行的。而記憶體是一個限制因素(大小)。除此之外,託管堆也有大小限制。如果託管堆沒有大小限制,那麼C#的執行速度要優於c了(託管堆的結構讓它有比c運行時堆更快的物件分配速度)。因為位址空間和儲存的限制因素,託管堆要通過垃圾回收機制,來維持它的正常運作,確保物件的分配,不會「記憶體溢出」。

垃圾回收的基本原則

回收分為兩個階段:  標記 –> 壓縮

標記的過程,其實就是判斷物件是否可達的過程。當所有的根都檢查完畢後,堆中將包含可達(已標記)與不可達(未標記)物件。

標記完成後,進入壓縮階段。在這個階段中,垃圾回收器線性的遍歷堆,以尋找不可達物件的連續記憶體區塊。並把可達物件移到這裡以壓縮堆。這個過程有點類似磁碟空間的碎片整理。

如上圖所示,綠色框表示可達對象,黃色框為不可達對象。不可達到物件清除後,移動可達物件實現記憶體壓縮(變得更緊湊)。

壓縮之後,「指向這些物件的指標」的變數和CPU暫存器現在都會失效,垃圾回收器必須重新存取所有根,並修改它們來指向物件的新記憶體位置。這會造成顯著的性能損失。這個損失也是託管堆的主要缺點。

基於上述特點,垃圾回收引發的回收演算法也是一項研究主題。因為如果真等到託管堆滿才開始執行垃圾回收,那就真的太「慢」了。

垃圾回收演算法 – 分代(Generation)演算法

#是CLR垃圾回收器採用的一種機制,它唯一的目的就是提升應用程式的效能。分代回收,速度顯然快於回收整個堆。

CLR託管堆支援3代:第0代,第1代,第2代。第0代的空間約256KB,第1代約2M,第2代約10M。新建構的物件會被分配到第0代,

如上圖所示,當第0代的空間滿時,垃圾回收器啟動回收,不可達物件(上圖C、E)會被回收,存活的物件被歸類為第1代。

當第0代空間已滿,第1代也開始有很多不可達物件以至空間將滿時,這時兩代垃圾都將被回收。存活下來的對象(可達對象),第0代升為第1代,第1代升為第2代。

實際CLR的代回收機制更加“智能”,如果新創建的對像生存週期很短,第0代垃圾也會立刻被垃圾回收器回收(不用等空間分配滿)。另外,如果回收了第0代,發現還有很多物件“可達”,

並沒有釋放多少內存,就會增大第0代的預算至512KB,回收效果就會轉變為:垃圾回收的次數將減少,但每次都會回收大量的記憶體。如果還沒有釋放多少內存,垃圾回收器將執行

完全回收(3代),如果還是不夠,則會拋出“內存溢出”異常。

也就是說,垃圾回收器會根據回收記憶體的大小,動態的調整每一代的分配空間預算!達到自動優化!

總結

垃圾回收背後有這樣一個基本的觀念:程式語言(大多數的)似乎總是能存取無限的記憶體。而開發者可以一直分配、分配再分配──像魔法一樣,取之不盡用之不竭。

.NET垃圾回收器的基本運作原理是:透過最基本的標記清除原理,清除不可達物件;再像磁碟碎片整理一樣壓縮、整理可用記憶體;最後透過分代演算法實現效能最最佳化.

以上是解析.NET垃圾回收(GC)原理的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn