作者：京東科技 康志興

1 JVM運行時記憶體劃分

1.1 運行時資料區域

? 方法區

屬于共享記憶體區域，存盤已被虛擬機加載的類資訊、常量、靜態變數、即時編譯器編譯后的代碼等資料，運行時常量池，屬于方法區的一部分，用于存放編譯期生成的各種字面量和符號參考，

JDK1.8之前，Hotspot虛擬機對方法區的實作叫做永久代，1.8之后改為元空間，二者區別主要在于永久代是在JVM虛擬機中分配記憶體，而元空間則是在本地記憶體中分配的，很多類是在運行期間加載的，它們所占用的空間完全不可控，所以改為使用本地記憶體，避免對JVM記憶體的影響，根據《Java虛擬機規范》的規定，如果方法區無法滿足新的記憶體分配需求時，將拋出OutOfMemoryError例外，

? 堆

執行緒共享，主要是存放物件實體和陣列，如果在Java堆中沒有記憶體完成實體分配，并且堆也無法再擴展時，Java虛擬機將會拋出OutOfMemoryError例外，PS：實際上寫入時并不完全共享，JVM會為執行緒在堆上劃分一塊專屬的分配緩沖區來提高物件分配效率，詳見：TLAB

? 虛擬機堆疊

執行緒私有，方法執行的程序就是一個個堆疊幀從入堆疊到出堆疊的程序，每個方法在執行時都會創建一個堆疊幀(Stack Frame)用于存盤區域變數表、運算元堆疊、動態鏈接、方法出口等資訊，如果執行緒入堆疊的堆疊幀超過限制就會拋出StackOverFlowError，如果支持動態擴展，那么擴展時申請記憶體失敗則拋出OutOfMemoryError，

? 本地方法堆疊

和虛擬機堆疊的功能類似，區別是作用于Native方法，

? 程式計數器

執行緒私有，記錄著當前執行緒所執行的位元組碼的行號，其作用主要是多執行緒場景下，記錄執行緒中指令的執行位置，以便被掛起的執行緒再次被激活時，CPU能從其掛起前執行的位置繼續執行，唯一一個在 Java 虛擬機規范中沒有規定任何 OutOfMemoryError 情況的區域，注意：如果執行緒執行的是個java方法，那么計數器記錄虛擬機位元組碼指令的地址，如果為native（底層方法），那么計數器為空，

1.2 物件的記憶體布局

在 HotSpot 虛擬機中，物件分為如下3塊區域：

? 物件頭(Header)運行時資料：哈希碼、GC分代年齡、鎖狀態標志、偏向執行緒ID、偏向時間戳等，型別指標：物件的型別元資料的指標，如果物件是資料，還會記錄陣列長度，

? 物件實體資料(Instance Data)包含物件真正的內容，即其包括父類所有欄位的值，

? 對齊填充(Padding)物件大小必須是是8位元組的整數倍，所以物件大小不滿足這個條件時，需要用對齊填充來補齊，

2 標記的方法和流程

2.1 判斷物件是否需要被回收

要分辨一個物件是否可以被回收，有兩種方式：參考計數法和可達性演算法，

? 參考計數法就是在物件被參考時，計數加1，參考斷開時，計數減1，那么一個物件的參考計數為0時，說明這個物件可以被清除，這個演算法的問題在于，如果A物件參考B的同時，B物件也參考A，即回圈參考，那么雖然雙方的參考計數都不為0，但如果僅僅被對方參考實際上沒有存在的價值，應該被GC掉，

? 可達性演算法通過參考計數法的缺陷可以看出，從被參考一方去判定其是否應該被清理過于片面，所以我們可以通過相反的方向去定位物件的存活價值：一個存活物件參考的所有物件都是不應該被清除的（Java中軟參考或弱參考在GC時有不同判定表現，不在此深究），這些查找起點被稱為GC Root，

2.2 哪些物件可以作為GC Root呢？

1. JAVA虛擬機堆疊中的本地變數參考物件

2. 方法區中靜態變數參考的物件

3. 方法區中常量參考的物件

4. 本地方法堆疊中JNI參考的物件

2.3 快速找到GC Root - OopMap

堆疊與暫存器都是無狀態的，保守式垃圾收集會直接線性掃描堆疊，再判斷每一串數字是不是參考，而HotSpot采用準確式垃圾收集方式，所有物件都存放在OopMap（Ordinary Object Pointer）中，當GC發生時，直接從這個map中尋找GC Root，

將GC Root存放到OopMap有兩個觸發時間點：

1. 類加載完成后，HotSpot就會把物件內什么偏移量上是什么型別的資料計算出來，

2. 即時編譯程序中，也會在特定的位置記錄下堆疊里和暫存器里哪些位置是參考，

2.4 更新OopMap的時機 - 安全點

導致OopMap更新的指令非常多，所以HotSpot只在特定位置進行記錄更新，這些位置叫做安全點，安全點位置的選取的標準是：“是否具有讓程式長時間執行”，比如方法呼叫、回圈跳轉、例外跳出等等，

2.5 可達性分析程序

三色標記法

? 白色：表示垃圾回收程序中，尚未被垃圾收集器訪問過的物件，在可達性分析開始階段，所有物件都是白色的，即不可達，

? 黑色：被垃圾收集器訪問過的物件，且這個物件所有的參考均掃描過，黑色的物件是安全存活的，如果其他物件被訪問時發現其參考了黑色物件，該黑色物件也不會再被掃描，

? 灰色：被垃圾收集器訪問過的物件，但這個物件至少有一個參考的物件沒有被掃描過，那么標記階段就是從GC Root的開始，沿著其參考鏈將每一個物件從白色標記為灰色最后標記為黑色的程序，

標記程序中不一致問題

由于這個階段是層層遞進的標記，所以程序中難免出現不一致的情況導致原本是黑色的物件被標記為白色，比如，當前掃描到B物件了，C物件尚未被訪問時，標記情況如下：

那么如果這時A物件取消了對B物件的參考，而GC Root增加了對C物件的參考，GC Root作為黑色標記不會再次被掃描，那么C物件在標記階段結束后仍然會保持白色，就會被清除掉，

解決方式

? 增量更新

當黑色物件增加了對白色物件的參考時，將其從黑色改為灰色，等并發標記階段結束后，從GC Root開始順著物件圖再將灰色物件重新掃描一次，這個掃描程序會STW，不會再次產生不一致問題，CMS就采用了這種方式，

? 原始快照（SATB）

當灰色物件洗掉了白色物件的參考時，將其記錄在執行緒獨占的SATB Queue中，讓其在標記階段結束后被再次掃描， G1、Shenandoah采用了這種方式，

示例

我們通過一個例子來展示兩種處理方式的不同，比如正常標記到物件A時，將其標記為灰色：

此時，用戶執行緒發生如下行為：

1. GC Root直接參考了C

2. A取消了參考B

理論上，C仍然是可達物件，不應被清除，而B不可達，應當被清除，

增量更新會記錄行為1，將GC Root標記為灰色，B不能訪問到被標記為可以回收：

等到重新標記階段再次訪問灰色的GC Root，順序將GC Root和C標記為黑色：

而原始快斬訓記錄行為2，將發生參考變化的物件全部記錄下來，等到重新標記階段再次訪問這些灰色，將其標記為黑色并順著物件圖掃描，

那么最終B作為浮動垃圾就被保存下來了，只能等到下一次GC時才能被回收，

3 分代模型

3.1 分代假說

弱分代假說（WeakGenerationalHypothesis）：絕大多數物件都是朝生夕滅的， 強分代假說（StrongGenerationalHypothesis）：熬過越多次垃圾收集程序的物件就越難以消亡， 跨代參考假說（IntergenerationalReferenceHypothesis）：跨代參考相對于同代參考來說僅占極少數，

上述假說是根據實際經驗得來的，由此垃圾收集器通常分為“年輕代”和“年老代”：

? 年輕代用來存放不斷生成且生命周期短暫的物件，收集動作相對高頻

? 年老代用來存放經歷多次GC仍然存活的物件，收集動作相對低頻

3.2 空間分配擔保

如果在GC后新生代存貨物件過多，Survivor無法容納，那么將會把這些物件直接送入年老代，這就叫年老代進行了“分配擔保”， 為了保證年老代能夠足夠空間容納這些直接晉升的物件，在發生Minor GC之前，虛擬機必須先檢查年老代最大可用的連續空間，如果大于新生代所有物件總空間或者歷次晉升的平均大小，就會進行MinorGC，否則將進行FullGC以同時清理年老代，

3.3 記憶集和卡表

記憶集是一種用于記錄從非收集區域指向收集區域的指標集合的抽象資料結構，

記憶集的作用

新生代發生垃圾收集時（Minor GC），如果想確定這個新生代物件是否被年老代的物件參考，則需要掃描整個年老代，成本非常高，

如果我們能知道哪一部分年老代可能存在對新生代的參考，就可以降低掃描范圍，

所以我們可以在新生代建立一個全域資料結構叫“記憶集（Remembered Set）”，這個結構把年老代分為若干個小塊，標記了哪些小塊記憶體中存在參考了新生代物件的情況，等到Minor GC時，只掃描這部分存在跨代參考的記憶體塊即可，雖然在物件變化時增加了維護記憶集的成本，但相比垃圾收集時掃描整個年老代來說是值得的，

JVM通常在物件增加參考前設定寫屏障判斷是否發生跨代參考，如果有跨代情況，則更新記憶集，

卡表

實作記憶集時，可以有不同精度的粒度：可以指向記憶體地址，也可以指向某個物件，或者指向某一塊記憶體區域，精度越低，維護成本越低，指向某一塊記憶體區域的實作方式就是“卡表”，卡表通常就是一個byte陣列，陣列中每一個元素代表某一塊記憶體，其值是1或者0：當發生跨代參考時，就表示該元素“dirty”了，那么將將其設定為1，否則就是0，

4 垃圾回收演算法

4.1 標記-清除（Mark-Sweep）

GC分為兩個階段，標記和清除，首先標記所有可回收的物件，在標記完成后統一回收所有被標記的物件，

缺點是清除后會產生不連續的記憶體碎片，碎片過多會導致以后程式運行時需要分配較大物件時，無法找到足夠的連續記憶體，而不得已再次觸發GC，

4.2 標記-復制（Mark-Copy）

將記憶體按容量劃分為兩塊，每次只使用其中一塊，當這一塊記憶體用完了，就將存活的物件復制到另一塊上，然后再把已使用的記憶體空間一次清理掉，

這樣使得每次都是對半個記憶體區回收，也不用考慮記憶體碎片問題，簡單高效，

缺點需要兩倍的記憶體空間，

一種優化方式是使用eden和survivior區，具體步驟如下：

eden和survivior區默認記憶體空間占比為8:1:1，同一時間只使用eden區和其中一個survivior區，標記完成后，將存活物件復制到另一個未使用的survivior區（部分年齡過大的物件將升級到年老代），

這種做法，相比普通的兩塊空間的標記復制演算法來說，只有10%的記憶體空間浪費，而這樣做的原因是：大部分情況下，一次young gc后剩余的存活物件非常少，

4.3 標記-整理（Mark-Compact）

標記-整理也分為兩個階段，首先標記可回收的物件，再將存活的物件都向一端移動，然后清理掉邊界以外的記憶體，

此方法避免標記-清除演算法的碎片問題，同時也避免了復制演算法的空間問題， 一般年輕代中執行GC后，會有少量的物件存活，就會選用復制演算法，只要付出少量的存活物件復制成本就可以完成收集，

而年老代中因為物件存活率高，用標記復制演算法時資料復制效率較低，且空間浪費較大，所以需要使用標記-清除或者標記-整理演算法來進行回收，

所以通常可以先使用標記清除演算法，當碎片率高時，再使用標記整理演算法，

5 最后

本篇介紹了JVM中垃圾回收器相關的基礎知識，后續會深入介紹CMS、G1、ZGC等不同垃圾收集器的運作流程和原理，歡迎關注，

標籤：其他

上一篇：記一次jedis連接池頑固問題排查與修改

下一篇：返回列表