1. G1垃圾回收器 1.1. 垃圾優先（garbage first） 1.2. 在堆內離散的區域上進行操作 1.2.1. 預設大約有2048個 1.2.2. 代的區域不需要是連續的 1.2.3. 可能屬於老年代 1.2.3.1. 併發後臺線程尋找沒有被引用的對象時，一些區域會比其他區域有更多的垃圾 ...
1. G1垃圾回收器
1.1. 垃圾優先（garbage first）
1.2. 在堆內離散的區域上進行操作
1.2.1. 預設大約有2048個
1.2.2. 代的區域不需要是連續的
1.2.3. 可能屬於老年代
- 1.2.3.1. 併發後臺線程尋找沒有被引用的對象時，一些區域會比其他區域有更多的垃圾
1.2.4. 可能屬於新生代
1.3. 併發回收器（concurrent collector）
1.3.1. 標記老年代中不使用的對象和應用程式線程同時發生（它們同時運行）
1.3.2. 並不是完全併發的
-
1.3.2.1. 新生代的標記和壓縮仍需要暫停所有應用程式線程
-
1.3.2.2. 老年代的壓縮也是在應用程式線程暫停期間發生的
1.4. 停頓
1.4.1. 較長的Full GC停頓
- 1.4.1.1. 理想情況下，你已經優化得足夠好，就不會發生這種情況
1.4.2. 較短的Young GC停頓
- 1.4.2.1. 包括回收和壓縮部分老年代的混合回收
1.4.3. 非常短的標記線程停頓
1.5. 4個邏輯操作
1.5.1. 新生代回收
- 1.5.1.1. Young GC
1.5.2. 後臺併發標記周期
-
1.5.2.1. 第一個階段
-
1.5.2.1.1. JDK 8中被稱為初始標記（initial mark）
-
1.5.2.1.2. JDK 11中被稱為併發開始（concurrent start）
-
1.5.2.1.2.1. 大小以區域為單位，而不是MB
-
1.5.2.1.2.2. 一個新的區域：巨型對象區域，是老年代的一部分
-
-
1.5.2.1.3. 暫停所有的應用程式線程
-
-
1.5.2.2. 重新標記（remark）階段
- 1.5.2.2.1. 會暫停應用程式線程，不過時間通常比較短
-
1.5.2.3. 正常的清理（cleanup）階段
- 1.5.2.3.1. 會暫停應用程式線程，不過時間通常比較短
1.5.3. Mixed GC
-
1.5.3.1. 混合垃圾回收
-
1.5.3.2. 執行正常的新生代回收時，也會回收後臺掃描時標記的一些區域
-
1.5.3.3. 在JDK 11中，首次Mixed GC被標記為Prepared Mixed，緊接著是併發清理
-
1.5.3.4. 將執行多次，持續到（幾乎）所有標記的區域都完成回收,恢復常規的Young GC周期
1.5.4. 必要的Full GC
-
1.5.4.1. 併發模式失敗（concurrent mode failure）
-
1.5.4.1.1. 老年代在這個標記周期完成之前被填滿了
-
1.5.4.1.2. 應該增加堆的大小
-
1.5.4.1.3. G1 GC的後臺處理必須更快
-
1.5.4.1.4. 必須優化標記周期以更快地運行
-
-
1.5.4.2. 晉升失敗（promotion failure）
-
1.5.4.2.1. 已經開始執行Mixed GC以清理老年代的區域。在它還沒有清理出足夠的空間之前，有太多的對象從新生代晉升，以至於老年代的空間還是用完了
-
1.5.4.2.2. 混合回收需要執行得更快
-
1.5.4.2.3. 每次新生代回收都需要處理更多的老年代區域
-
-
1.5.4.3. 疏散失敗（evacuation failure）
-
1.5.4.3.1. 堆已經非常滿了或者碎片化很嚴重
-
1.5.4.3.2. 增加堆的大小
-
-
1.5.4.4. 巨型對象分配失敗（humongous allocation failure）
-
1.5.4.5. 元數據GC閾值（metadata GC threshold）
-
1.5.4.5.1. 元空間本質上是一個獨立的堆，並且獨立於主堆進行回收
-
1.5.4.5.2. 在JDK 8中，當它需要進行回收時，G1 GC會在主堆上執行Full GC（緊跟著新生代回收）
-
1.5.4.5.3. 在JDK 11中，元空間可以被回收，也可以調整大小，而不必進行Full GC
-
1.6. 運行G1的JVM經過良好優化後應該只經歷Young GC、Mixed GC和併發GC周期
2. 優化G1 GC
2.1. 目標是確保沒有因併發模式失敗或疏散失敗而產生Full GC
2.1.1. 從設置合理的停頓時間目標開始
2.2. 在JDK 8中執行Full GC時，使用的是單線程，這就會造成停頓時間比平常更長
2.3. 在JDK 11中，Full GC由多個線程執行，從而使停頓時間更短
2.4. 增加老年代的大小，增加堆空間的總大小，或者調整分代比例
2.5. 增加後臺線程的數量（假設有足夠的CPU）
2.6. 更頻繁地執行G1 GC後臺活動
2.7. 增加Mixed GC周期的工作量
2.8. -XX:MaxGCPauseMillis=N標誌
2.8.1. 該標誌有預設值，即200毫秒
2.9. 優化G1後臺線程
2.9.1. -XX:ParallelGCThreads=N標誌
- 2.9.1.1. 影響應用程式線程暫停階段的線程數量
2.9.2. -XX:ConcGCThreads=N標誌
-
2.9.2.1. 影響用於併發標記的線程數量
-
2.9.2.2. 如果有額外的CPU可用
-
2.9.2.3. 計算方式
-
2.9.2.3.1. ConcGCThreads = (ParallelGCThreads + 2) / 4
-
2.9.2.3.2. 基於整數的
-
2.10. 優化G1 GC的運行頻率
2.10.1. G1 GC提前開始後臺標記周期，也可以儘量減少Full GC
2.10.2. 當堆達到-XX:InitiatingHeapOccupancyPercent=N設定的占用率時，這個周期才會開始
2.10.3. -XX:InitiatingHeapOccupancyPercent=N
-
2.10.3.1. 預設值是45，表示老年代占整個堆的比例
-
2.10.3.2. 為了讓後臺線程運行得更頻繁
2.11. 優化G1 GC的Mixed GC周期
2.11.1. 在Mixed GC周期中處理更多的區域
2.11.2. -XX:G1MixedGCCountTarget=N標誌
-
2.11.2.1. 處理區域時Mixed GC周期的最大總次數
-
2.11.2.2. 混合周期的數量上限
-
2.11.2.3. 預設值是8
-
2.11.2.4. 減小該值有助於解決晉升失敗的問題（代價是Mixed GC周期的停頓時間更長）
2.11.3. MaxGCPauseMillis設定
-
2.11.3.1. GC可接受的最大停頓毫秒數
-
2.11.3.2. 增加MaxGCPauseMillis標誌的值，可以在每次Mixed GC期間回收更多的老年代區域
3. JDK 12引入的回收器
3.1. 現存的併發回收器並不是完全併發的
3.1.1. G1 GC和CMS回收器都沒有新生代的併發回收，回收新生代需要暫停所有應用程式線程
3.1.2. 沒有進行併發壓縮
3.2. Z垃圾回收器（Z garbage collector，ZGC）
3.2.1. 在JDK 11中首次出現
3.2.2. AdoptOpenJDK構建的JVM（或者你自己從源碼編譯的JDK）包含
3.2.3. Oracle構建的JVM包含
3.3. Shenandoah垃圾回收器
3.3.1. 在JDK 12中首次出現
3.3.2. 已經被向後移植到了JDK 8和JDK 11中
3.3.3. AdoptOpenJDK構建的JVM（或者你自己從源碼編譯的JDK）包含
3.4. -XX:+UnlockExperimentalVMOptions
3.4.1. 預設情況下是false
3.5. -XX:+UseZGC
3.6. -XX:+UseShenandoahGC
3.7. 都可以併發壓縮堆
3.7.1. 可以在不暫停所有應用程式線程的情況下移動堆中的對象
3.7.2. 堆不再需要分代（不再有新生代和老年代了，只有一個堆）
3.7.3. 應用程式線程的操作延遲預期會減少（至少在很多情況下會）
3.8. ZGC和Shenandoah會有在很短的時間內，所有的應用程式線程都會暫停
3.8.1. 目標是將這些時間保持在非常短的水平，即在10毫秒左右
3.9. 併發壓縮對延遲的影響
3.9.1. 垃圾回收的停頓一般是造成延遲異常的最大原因
3.10. 併發壓縮回收器對吞吐量的影響
3.10.1. 併發壓縮回收器通常會比G1 GC後臺線程執行更多的後臺處理
3.10.2. 沒有足夠的CPU周期，回收器也會出現之前看到的併發失敗，最終發生Full GC
3.10.3. 有足夠的CPU，那麼使用這兩種回收器時的吞吐量將高於G1 GC或Throughput回收器的吞吐量
4. Epsilon回收器
4.1. JDK 11的一個什麼都不做的回收器
4.1.1. 為JDK內部測試設計的
4.1.2. 對象永遠不會從堆中回收，當堆被填滿時，你會得到一個記憶體溢出錯誤的提示
4.2. 你確定程式需要的記憶體永不會比你提供的大
4.3. 一旦遇到了適用Epsilon回收器的情況，它會帶來很好的性能提升
4.4. 兩種情況下是有用的
4.4.1. 存活時間非常短的應用程式
4.4.2. 特意編寫的、重覆使用記憶體並且永遠不執行新分配的應用程式
- 4.4.2.1. 在某些記憶體受限的嵌入式環境中很有用
