一、記憶體模型及磁區

　　JVM 是可運行 Java 代碼的假想計算機 ，包括一套位元組碼指令集、一組暫存器、一個堆疊、一個垃圾回收，堆 和 一個存盤方法域，JVM 是運行在作業系統之上的，它與硬體沒有直接的互動，

　　

 

　　JVM 分為堆區和堆疊區，還有方法區，初始化的物件放在堆里面，參考放在堆疊里面，class 類資訊常量池（static 常量和 static 變數）等放在方法區，

　　

1.1、堆疊（Stack-執行緒私有）

　1.1.1 堆疊的結構是堆疊幀組成的，呼叫一個方法就壓入一幀，幀上面存盤區域變數表，運算元堆疊，方法出口等資訊，每一個方法從呼叫直至執行完成的程序，就對應著一個堆疊幀在虛擬機堆疊中入堆疊到出堆疊的程序，區域變數表存放的是 8 大基礎型別加上一個參考型別，所以還是一個指向地址的指標，運算元堆疊的作用主要用來存盤運算結果以及運算的運算元，它不同于區域變數表通過索引來訪問，而是壓堆疊和出堆疊的方式，

　　堆疊幀（Stack Frame）是用來存盤資料和部分程序結果的資料結構，同時也被用來處理動態鏈接(Dynamic Linking)、 方法回傳值和例外分派（ Dispatch Exception），堆疊幀隨著方法呼叫而創建，隨著方法結束而銷毀——無論方法是正常完成還是例外完成（拋出了在方法內未被捕獲的例外）都算作方法結束，

　1.1.2 JVM為每個執行緒創建一個堆疊，用于存盤該執行緒執行方法的資訊（實際引數、區域變數等），與執行緒的生命周期相同，

　1.1.3 堆疊的特性：后進先出；由系統自動分配速度快且堆疊是一個連續的存盤空間，

1.2、堆（Heep-執行緒共享）---運行時資料區

　1.2.1 是被執行緒共享的一塊記憶體區域，創建的物件和陣列都保存在 Java 堆記憶體中，也是垃圾收集器進行垃圾收集的最重要的記憶體區域，由于現代 VM 采用分代收集演算法, 因此 Java 堆從 GC 的角度還可以細分為: 新生代(Eden 區、From Survivor 區和 To Survivor 區)和老年代，

　1.2.2 JVM只有一個堆，被所有執行緒所共享，

　1.2.3 堆是一個不連續的存盤空間，分配靈活但速度慢，

1.3、方法區/永久代（執行緒共享）：

　1.3.1 主要是存盤類資訊，常量池（static 常量和 static 變數），編譯后的代碼（位元組碼）等資料 (永遠不變或唯一的內容) ，

　1.3.2 我們常說的永久代(Permanent Generation), 用于存盤被 JVM 加載的類資訊、常量、靜態變數、即時編譯器編譯后的代碼等資料. HotSpot VM把GC分代收集擴展至方法區, 即使用Java堆的永久代來實作方法區, 這樣 HotSpot 的垃圾收集器就可以像管理 Java 堆一樣管理這部分記憶體,而不必為方法區開發專門的記憶體管理器(永久帶的記憶體回收的主要目標是針對常量池的回收和型別的卸載, 因此收益一般很小)

　1.3.3 運行時常量池（Runtime Constant Pool）是方法區的一部分，Class 檔案中除了有類的版本、欄位、方法、介面等描述等資訊外，還有一項資訊是常量池（Constant Pool Table），用于存放編譯期生成的各種字常量和符號參考，這部分內容將在類加載后存放到方法區的運行時常量池中， Java 虛擬機對 Class 檔案的每一部分（自然也包括常量池）的格式都有嚴格的規定，每一個位元組用于存盤哪種資料都必須符合規范上的要求，這樣才會被虛擬機認可、裝載和執行，

　1.3.4 JVM只有一個方法區，被所有執行緒共享，

　1.3.5 方法區實際上也是堆，只是用來存盤類、常量相關的資訊，

　1.3.6 版本變換

1. 在JDK1.7以前HotSpot虛擬機使用永久代來實作方法區，永久代的大小在啟動JVM時可以設定一個固定值（-XX:MaxPermSize），不可變；

2. 在JDK1.7中 存盤在永久代的部分資料就已經轉移到Java Heap或者Native memory，譬如符號參考(Symbols)轉移到了native memory，原本存放在永久代的字符常量池移出，但永久代仍存在于JDK 1.7中，并沒有完全移除，

3. JDK1.8中進行了較大改動

   1. 移除了永久代（PermGen），替換為元空間（Metaspace）；
   2. 永久代中的 class metadata 轉移到了 native memory（本地記憶體，而不是虛擬機）；
   3. 永久代中的 interned Strings 和 class static variables 轉移到了 Java heap；
   4. 永久代引數 （PermSize MaxPermSize） -> 元空間引數（MetaspaceSize MaxMetaspaceSize）

1.4、本地方法堆疊(執行緒私有)

　本地方法區和 Java Stack 作用類似, 區別是虛擬機堆疊為執行 Java 方法服務, 而本地方法堆疊則為Native 方法服務, 如果一個 VM 實作使用 C-linkage 模型來支持 Native 呼叫, 那么該堆疊將會是一個C 堆疊，但 HotSpot VM 直接就把本地方法堆疊和虛擬機堆疊合二為一，

1.5、程式計數器(執行緒私有)

　一塊較小的記憶體空間, 是當前執行緒所執行的位元組碼的行號指示器，每條執行緒都要有一個獨立的程式計數器，這類記憶體也稱為“執行緒私有”的記憶體，正在執行 java 方法的話，計數器記錄的是虛擬機位元組碼指令的地址（當前指令的地址），如果還是 Native 方法，則為空，這個記憶體區域是唯一一個在虛擬機中沒有規定任何 OutOfMemoryError 情況的區域，

　　

二、Minor GC、Major GC、Full GC

2.1 Minor GC

　新生代 GC（Minor GC）：從年輕代空間（包括 Eden 和 Survivor 區域）回收記憶體被稱為 Minor GC,因為 Java 物件大多都具備朝生夕滅的特性，所以 Minor GC 非常頻繁，一般回收速度也比較快，這一定義既清晰又易于理解，但是，當發生Minor GC事件的時候，有一些有趣的地方需要注意到：

　　2.1.1  當 JVM 無法為一個新的物件分配空間時會觸發 Minor GC，比如當 Eden 區滿了，所以分配率越高，越頻繁執行 Minor GC，

　　2.1.2  記憶體池被填滿的時候，其中的內容全部會被復制，指標會從0開始跟蹤空閑記憶體，Eden 和 Survivor 區進行了標記和復制操作，取代了經典的標記、掃描、壓縮、清理操作，所以 Eden 和 Survivor 區不存在記憶體碎片，寫指標總是停留在所使用記憶體池的頂部，

　　2.1.3 執行 Minor GC 操作時，不會影響到永久代，從永久代到年輕代的參考被當成 GC roots，從年輕代到永久代的參考在標記階段被直接忽略掉，

　　2.1.4 所有的 Minor GC 都會觸發“全世界的暫停（stop-the-world）”，停止應用程式的執行緒，對于大部分應用程式，停頓導致的延遲都是可以忽略不計的，其中的真相就 是，大部分 Eden 區中的物件都能被認為是垃圾，永遠也不會被復制到 Survivor 區或者老年代空間，如果正好相反，Eden 區大部分新生物件不符合 GC 條件，Minor GC 執行時暫停的時間將會長很多，
所以 Minor GC 的情況就相當清楚了——每次 Minor GC 會清理年輕代的記憶體，

　　2.1.5 觸發機制：當年輕代滿時就會觸發Minor GC，這里的年輕代滿指的是Eden代滿，Survivor滿不會引發GC，

2.2 Major GC

　Major GC清理Tenured區，用于回收老年代，出現Major GC通常會出現至少一次Minor GC，

　Major GC的觸發條件：當年老代空間不夠用的時候，虛擬機會使用“標記—清除”或者“標記—整理”演算法清理出連續的記憶體空間，分配物件使用，

　　注意：也有認為是和full GC是等價的，收集整個GC堆，但因為HotSpot VM發展了這么多年，外界對各種名詞的解讀已經完全混亂了，當有人說“major GC”的時候一定要問清楚他想要指的是上面的old GC（只清理老年代）還是 full GC，

2.3 Full GC

　Full GC是針對整個新生代、老生代、元空間（metaspace，java8以上版本取代perm gen）的全域范圍的GC，Full GC不等于Major GC，也不等于Minor GC+Major GC，發生Full GC需要看使用了什么垃圾收集器組合，才能解釋是什么樣的垃圾回收，

　Full GC觸發條件：

　　2.3.1 呼叫System.gc時，系統建議執行Full GC，但是不必然執行

　　2.3.2 老年代空間不足

　　2.3.3 方法去空間不足

　　2.3.4 通過Minor GC后進入老年代的平均大小大于老年代的可用記憶體

　　2.3.5 由Eden區、From Space區向To Space區復制時，物件大小大于To Space可用記憶體，則把該物件轉存到老年代，且老年代的可用記憶體小于該物件大小

三、JVM運行時記憶體

 　　Java 堆從 GC 的角度還可以細分為: 新生代(Eden 區、From Survivor 區和 To Survivor 區)和老年代，   　

3.1、新生代

　　是用來存放新生的物件，一般占據堆的 1/3 空間，由于頻繁創建物件，所以新生代會頻繁觸發MinorGC 進行垃圾回收，新生代又分為 Eden 區、ServivorFrom、ServivorTo 三個區，

　3.1.1 Eden 區

　　Java 新物件的出生地（如果新創建的物件占用記憶體很大，則直接分配到老年代），當 Eden 區記憶體不夠的時候就會觸發 MinorGC，對新生代區進行一次垃圾回收，

　3.1.2 ServivorFrom 區

　　上一次 GC 的幸存者，作為這一次 GC 的被掃描者，

　3.1.3 ServivorTo區

　　保留了一次 MinorGC 程序中的幸存者，

　3.1.4 MinorGC 的程序（復制->清空->互換）

　　MinorGC 采用復制演算法，

　　3.1.4.1 eden、servivorFrom 復制到 ServivorTo，年齡+1

　　　　首先，把 Eden 和 ServivorFrom 區域中存活的物件復制到 ServivorTo 區域（如果有物件的年齡已經達到了老年的標準，則賦值到老年代區），同時把這些物件的年齡+1（如果 ServivorTo 不夠位置了就放到老年區）；虛擬機會給每個物件定義一個物件年齡(Age)計數器，物件在Survivor區中每“熬過”一次GC，年齡就會+1，待到年齡到達一定歲數(默認是15歲)，虛擬機就會將物件移動到年老代，

　　3.1.4.2 清空 eden、servivorFrom

　　　　然后，清空 Eden 和 ServivorFrom 中的物件；

　　3.1.4.3 ServivorTo 和 ServivorFrom 互換

　　　　最后，ServivorTo 和 ServivorFrom 互換，原 ServivorTo 成為下一次 GC 時的 ServivorFrom區，

3.2、老年代

　主要存放應用程式中生命周期長的記憶體物件，

　老年代的物件比較穩定，所以 MajorGC 不會頻繁執行，在進行 MajorGC 前一般都先進行了一次 MinorGC，使得有新生代的物件晉身入老年代，導致空間不夠用時才觸發，當無法找到足夠大的連續空間分配給新創建的較大物件時也會提前觸發一次 MajorGC 進行垃圾回收騰出空間，

　MajorGC 采用標記清除演算法：首先掃描一次所有老年代，標記出存活的物件，然后回收沒有標記的物件，MajorGC 的耗時比較長，因為要掃描再回收，MajorGC 會產生記憶體碎片，為了減少記憶體損耗，我們一般需要進行合并或者標記出來方便下次直接分配，當老年代也滿了裝不下的時候，就會拋出 OOM（Out of Memory）例外，

3.3、永久代 

 　指記憶體的永久保存區域，主要存放 Class 和 Meta（元資料）的資訊,Class 在被加載的時候被放入永久區域，它和和存放實體的區域不同,GC 不會在主程式運行期對永久區域進行清理，所以這也導致了永久代的區域會隨著加載的 Class 的增多而脹滿，最終拋出 OOM 例外，

　在 Java8 中，永久代已經被移除，被一個稱為“元資料區”（元空間）的區域所取代，元空間的本質和永久代類似，元空間與永久代之間最大的區別在于：元空間并不在虛擬機中，而是使用本地記憶體，因此，默認情況下，元空間的大小僅受本地記憶體限制，類的元資料放入 native memory, 字串池和類的靜態變數放入 java 堆中，這樣可以加載多少類的元資料就不再由MaxPermSize 控制, 而由系統的實際可用空間來控制，

四、Java 垃圾回識訓制

 4.1、簡介：

　在 java 中，程式員是不需要顯示的去釋放一個物件的記憶體的，而是由虛擬機自行執行，在JVM 中，有一個垃圾回收執行緒，它是低優先級的，在正常情況下是不會執行的，只有在虛擬機空閑或者當前堆記憶體不足時，才會觸發執行，掃描那些沒有被任何參考的物件，并將它們添加到要回收的集合中，進行回收，

4.2、如何確定是否是垃圾（物件是否存活）

　4.2.1 參考計數法

　　在 Java 中，參考和物件是有關聯的，如果要操作物件則必須用參考進行，因此，很顯然一個簡單的辦法是通過參考計數來判斷一個物件是否可以回收，簡單說，即一個物件如果沒有任何與之關聯的參考，即他的參考計數為 0，則說明物件不太可能再被用到，那么這個物件就是可回收物件， 

　　參考計數法有一個缺陷就是無法解決回圈參考問題，也就是說當物件 A 參考物件 B，物件B 又參考者物件 A，那么此時 A,B 物件的參考計數器都不為零，也就造成無法完成垃圾回收，所以主流的虛擬機都沒有采用這種演算法， 

　4.2.2 可達性演算法(參考鏈法) 

　　為了解決參考計數法的回圈參考問題，Java 使用了可達性分析的方法，通過一系列的“GC roots”物件作為起點搜索，如果在“GC roots”和一個物件之間沒有可達路徑，則稱該物件是不可達的，要注意的是，不可達物件不等價于可回收物件，不可達物件變為可回收物件至少要經過兩次標記程序，兩次標記后仍然是可回收物件，則將面臨回收， 

　　如果物件在可達性分析中沒有與 GC Root 的參考鏈，那么此時就會被第一次標記并且進行一次篩選，篩選的條件是是否有必要執行 finalize()方法，當物件沒有覆寫 finalize()方法或者已被虛擬機呼叫過，那么就認為是沒必要的，如果該物件有必要執行 finalize()方法，那么這個物件將會放在一個稱為 F-Queue 的對佇列中，虛擬機會觸發一個 Finalize()執行緒去執行，此執行緒是低優先級的，并且虛擬機不會承諾一直等待它運行完，這是因為如果 finalize()執行緩慢或者發生了死鎖，那么就會造成 FQueue 佇列一直等待，造成了記憶體回收系統的崩潰，GC 對處于 F-Queue 中的物件進行第二次被標記，這時，該物件將被移除”即將回收”集合，等待回收， 

　　在 java 中可以作為 GC Roots 的物件有以下幾種:

　　4.2.2.1 虛擬機堆疊中參考的物件 

　　4.2.2.2 方法區類靜態屬性參考的物件

　　4.2.2.3 方法區常量池參考的物件

　　4.2.2.4 本地方法堆疊 JNI 參考的物件

 4.3 垃圾收集方法

　4.3.1 標記清除演算法（Mark-Sweep）

　　最基礎的垃圾回收演算法，分為兩個階段，標注和清除，標記階段標記出所有需要回收的物件，清除階段回收被標記的物件所占用的空間，如圖 

　

 　　這種方法很簡單，但是會有兩個主要問題：

　　　1.效率不高，標記和清除的效率都很低；

　　　2.會產生大量不連續的記憶體碎片，導致以后程式在分配較大的物件時，由于沒有充足的連續記憶體而提前觸發一次 GC 動作，

　4.3.2 復制演算法（copying） 

　　為了解決 Mark-Sweep 演算法記憶體碎片化的缺陷而被提出的演算法，按記憶體容量將記憶體劃分為等大小的兩塊，每次只使用其中一塊，當這一塊記憶體滿后將尚存活的物件復制到另一塊上去，把已使用的記憶體清掉，如圖：

　 

 　　這種演算法雖然實作簡單，記憶體效率高，不易產生碎片，但是最大的問題是可用記憶體被壓縮到了原本的一半，且存活物件增多的話，Copying 演算法的效率會大大降低， 

　　于是將該演算法進行了改進，記憶體區域不再是按照 1：1 去劃分，而是將記憶體劃分為8:1:1 三部分，較大那份記憶體交 Eden 區，其余是兩塊較小的記憶體區叫 Survior 區，每次都會優先使用 Eden 區，若 Eden 區滿，就將物件復制到第二塊記憶體區上，然后清除 Eden 區，如果此時存活的物件太多，以至于 Survivor 不夠時，會將這些物件通過分配擔保機制復制到老年代中，(java 堆又分為新生代和老年代)，

　4.3.3  標記整理演算法(Mark-Compact) 

　　結合了以上兩個演算法，該演算法主要是為了解決標記-清除，產生大量記憶體碎片的問題；當物件存活率較高時，也解決了復制演算法的效率問題，它的不同之處就是在清除物件的時候現將可回收物件移動到一端，然后清除掉端邊界以外的物件，這樣就不會產生記憶體碎片了，

　　　

 　4.3.4 分代收集演算法

　　分代收集法是目前大部分 JVM 所采用的方法，其核心思想是根據物件存活的不同生命周期將記憶體劃分為不同的域，一般情況下將 GC 堆劃分為老生代(Tenured/Old Generation)和新生代(YoungGeneration)，老生代的特點是每次垃圾回收時只有少量物件需要被回收，新生代的特點是每次垃圾回收時都有大量垃圾需要被回收，因此可以根據不同區域選擇不同的演算法， 

　　4.3.4.1 新生代與復制演算法

　　　目前大部分 JVM 的 GC 對于新生代都采取 Copying 演算法，因為新生代中每次垃圾回收都要回收大部分物件，即要復制的操作比較少，但通常并不是按照 1：1 來劃分新生代，一般將新生代劃分為一塊較大的 Eden 空間和兩個較小的 Survivor 空間(From Space, To Space)，每次使用Eden 空間和其中的一塊 Survivor 空間，當進行回收時，將該兩塊空間中還存活的物件復制到另一塊 Survivor 空間中， 

　　　

 　　4.3.4.2 老年代與標記整理演算法 

 　　　而老年代因為每次只回收少量物件，因而采用 Mark-Compact 演算法，

　　　1. JAVA 虛擬機提到過的處于方法區的永久代(Permanet Generation)，它用來存盤 class 類，常量，方法描述等，對永久代的回收主要包括廢棄常量和無用的類， 　　　2. 物件的記憶體分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目前存放物件的那一塊)，少數情況會直接分配到老年代， 　　　3. 當新生代的 Eden Space 和 From Space 空間不足時就會發生一次 GC，進行 GC 后，EdenSpace 和 From Space 區的存活物件會被挪到 To Space，然后將 Eden Space 和 FromSpace 進行清理， 　　　4. 如果 To Space 無法足夠存盤某個物件，則將這個物件存盤到老生代， 　　　5. 在進行 GC 后，交換 FromSpace 和 To Space 了，如此反復回圈， 　　　6. 當物件在 Survivor 區躲過一次 GC 后，其年齡就會+1，默認情況下年齡到達 15 的物件會被移到老生代中  

　4.3.5 GC 分代收集演算法 VS 磁區收集演算法

　　4.3.5.1 分代收集演算法 

　　　當前主流 VM 垃圾收集都采用”分代收集”(Generational Collection)演算法, 這種演算法會根據物件存活周期的不同將記憶體劃分為幾塊, 如 JVM 中的 新生代、老年代、永久代，這樣就可以根據各年代特點分別采用最適當的 GC 演算法.

　　　在新生代-復制演算法: 每次垃圾收集都能發現大批物件已死, 只有少量存活. 因此選用復制演算法, 只需要付出少量存活物件的復制成本就可以完成收集.

　　　在老年代-標記整理演算法: 因為物件存活率高、沒有額外空間對它進行分配擔保, 就必須采用“標記—清理”或“標記—整理”演算法來進行回收, 不必進行記憶體復制, 且直接騰出空閑記憶體.

　　4.3.5.2 磁區收集演算法 　　　磁區演算法則將整個堆空間劃分為連續的不同小區間, 每個小區間獨立使用, 獨立回收. 這樣做的好處是可以控制一次回收多少個小區間 , 根據目標停頓時間, 每次合理地回收若干個小區間(而不是整個堆), 從而減少一次 GC 所產生的停頓，  

 4.4 GC 垃圾收集器

　Java 堆記憶體被劃分為新生代和年老代兩部分，新生代主要使用復制和標記-清除垃圾回收演算法；年老代主要使用標記-整理垃圾回收演算法，因此 java 虛擬中針對新生代和年老代分別提供了多種不同的垃圾收集器，JDK1.6 中 Sun HotSpot 虛擬機的垃圾收集器如下： 

 　　

 　4.4.1 Serial 垃圾收集器（單執行緒、復制演算法）

 　　Serial（英文連續）是最基本垃圾收集器，使用復制演算法，曾經是JDK1.3.1 之前新生代唯一的垃圾收集器，Serial 是一個單執行緒的收集器，它不但只會使用一個 CPU 或一條執行緒去完成垃圾收集作業，并且在進行垃圾收集的同時，必須暫停其他所有的作業執行緒，直到垃圾收集結束，Serial 垃圾收集器雖然在收集垃圾程序中需要暫停所有其他的作業執行緒，但是它簡單高效，對于限定單個 CPU 環境來說，沒有執行緒互動的開銷，可以獲得最高的單執行緒垃圾收集效率，因此 Serial垃圾收集器依然是 java 虛擬機運行在 Client 模式下默認的新生代垃圾收集器， 

 　4.4.2 ParNew 垃圾收集器（Serial+多執行緒） 

　　ParNew 垃圾收集器其實是 Serial 收集器的多執行緒版本，也使用復制演算法，除了使用多執行緒進行垃圾收集之外，其余的行為和 Serial 收集器完全一樣，ParNew 垃圾收集器在垃圾收集程序中同樣也要暫停所有其他的作業執行緒，ParNew 收集器默認開啟和 CPU 數目相同的執行緒數，可以通過-XX:ParallelGCThreads 引數來限制垃圾收集器的執行緒數，【Parallel：平行的】  ParNew雖然是除了多執行緒外和Serial 收集器幾乎完全一樣，但是ParNew垃圾收集器是很多 java虛擬機運行在 Server 模式下新生代的默認垃圾收集器， 

　4.4.3 Parallel Scavenge 收集器（多執行緒復制演算法、高效） 

　　Parallel Scavenge 收集器也是一個新生代垃圾收集器，同樣使用復制演算法，也是一個多執行緒的垃圾收集器，它重點關注的是程式達到一個可控制的吞吐量（Thoughput，CPU 用于運行用戶代碼的時間/CPU 總消耗時間，即吞吐量=運行用戶代碼時間/(運行用戶代碼時間+垃圾收集時間)），高吞吐量可以最高效率地利用 CPU 時間，盡快地完成程式的運算任務，主要適用于在后臺運算而不需要太多互動的任務，自適應調節策略也是 ParallelScavenge 收集器與 ParNew 收集器的一個重要區別，

　4.4.4 Serial Old 收集器（單執行緒標記整理演算法 ） 

　　Serial Old 是 Serial 垃圾收集器年老代版本，它同樣是個單執行緒的收集器，使用標記-整理演算法，這個收集器也主要是運行在 Client 默認的 java 虛擬機默認的年老代垃圾收集器，

　　在 Server 模式下，主要有兩個用途：
　　　1. 在 JDK1.5 之前版本中與新生代的 Parallel Scavenge 收集器搭配使用， 　　　2. 作為年老代中使用 CMS 收集器的后備垃圾收集方案，

　　新生代 Serial 與年老代 Serial Old 搭配垃圾收集程序圖： 

　　

　　新生代 Parallel Scavenge 收集器與 ParNew 收集器作業原理類似，都是多執行緒的收集器，都使用的是復制演算法，在垃圾收集程序中都需要暫停所有的作業執行緒，

　　新生代 ParallelScavenge/ParNew 與年老代 Serial Old 搭配垃圾收集程序圖：

　 　　

 　4.4.5 Parallel Old 收集器（多執行緒標記整理演算法） 

　　Parallel Old 收集器是Parallel Scavenge的年老代版本，使用多執行緒的標記-整理演算法，在 JDK1.6才開始提供， 在 JDK1.6 之前，新生代使用 ParallelScavenge 收集器只能搭配年老代的 Serial Old 收集器，只能保證新生代的吞吐量優先，無法保證整體的吞吐量，Parallel Old 正是為了在年老代同樣提供吞吐量優先的垃圾收集器，如果系統對吞吐量要求比較高，可以優先考慮新生代 Parallel Scavenge和年老代 Parallel Old 收集器的搭配策略， 
　　新生代 Parallel Scavenge 和年老代 Parallel Old 收集器搭配運行程序圖： 
　　

　4.4.6 CMS 收集器（多執行緒標記清除演算法） 

　　Concurrent mark sweep(CMS)收集器是一種年老代垃圾收集器，其最主要目標是獲取最短垃圾回收停頓時間，和其他年老代使用標記-整理演算法不同，它使用多執行緒的標記-清除演算法，最短的垃圾收集停頓時間可以為互動比較高的程式提高用戶體驗，

　　CMS 作業機制相比其他的垃圾收集器來說更復雜，整個程序分為以下 6 個階段： 　　

1. 初始標記：在這個階段，需要虛擬機停頓正在執行的任務，官方的叫法STW(Stop The Word)，這個程序從垃圾回收的"根物件"開始，只掃描到能夠和"根物件"直接關聯的物件，并作標記，所以這個程序雖然暫停了整個JVM，但是很快就完成了，

2. 并發標記：這個階段緊隨初始標記階段，在初始標記的基礎上繼續向下追溯標記，并發標記階段，應用程式的執行緒和并發標記的執行緒并發執行，所以用戶不會感受到停頓
   

3. 并發預清理：并發預清理階段仍然是并發的，在這個階段，虛擬機查找在執行并發標記階段新進入老年代的物件(可能會有一些物件從新生代晉升到老年代， 或者有一些物件被分配到老年代)，通過重新掃描，減少下一個階段"重新標記"的作業，因為下一個階段會Stop The World，

4. 重新標記：這個階段會暫停虛擬機，收集器執行緒掃描在CMS堆中剩余的物件，掃描從"根物件"開始向下追溯，并處理物件關聯，

5. 并發清理：清理垃圾物件，這個階段收集器執行緒和應用程式執行緒并發執行，

6. 并發重置：這個階段，重置CMS收集器的資料結構，等待下一次垃圾回收，

        CMS不會整理、壓縮堆空間，這樣就帶來一個問題：經過CMS收集的堆會產生空間碎片，CMS不對堆空間整理壓縮節約了垃圾回收的停頓時間，但也帶來的堆空間的浪費，         為了解決堆空間浪費問題，CMS回收器不再采用簡單的指標指向一塊可用堆空 間來為下次物件分配使用，；而是把一些未分配的空間匯總成一個串列，當JVM分配物件空間的時候，會搜索這個串列找到足夠大的空間來hold住這個物件  　　　　清除 GC Roots 不可達物件，和用戶執行緒一起作業，不需要暫停作業執行緒，由于耗時最長的并發標記和并發清除程序中，垃圾收集執行緒可以和用戶現在一起并發作業，所以總體上來看CMS 收集器的記憶體回收和用戶執行緒是一起并發地執行，

　　CMS 收集器作業程序： 

　　

 　4.4.7 G1 收集器 

　　Garbage first 垃圾收集器是目前垃圾收集器理論發展的最前沿成果，相比與 CMS 收集器，G1 收集器兩個最突出的改進是： 　　　1. 基于標記-整理演算法，不產生記憶體碎片， 　　　2. 可以非常精確控制停頓時間，在不犧牲吞吐量前提下，實作低停頓垃圾回收， 　　G1 收集器避免全區域垃圾收集，它把堆記憶體劃分為大小固定的幾個獨立區域，并且跟蹤這些區域的垃圾收集進度，同時在后臺維護一個優先級串列，每次根據所允許的收集時間，優先回收垃圾最多的區域，區域劃分和優先級區域回識訓制，確保 G1 收集器可以在有限時間獲得最高的垃圾收集效率，    

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/144548.html

標籤：Java

上一篇：BCB編譯成功后把exe檔案裝到別的電腦上，提示”由于找不到vcl60.bpl，無法繼續執行。。。。。“，怎么解決

下一篇：基數排序