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. 在某些記憶體受限的嵌入式環境中很有用

4.5. -XX:+UnlockExperimentalVMOptions

4.6. -XX:+UseEpsilonGC

標籤：其他

上一篇：zynq基于DMA的串口傳圖

下一篇：一天吃透TCP面試八股文