ZGC(Z Garbage Collector)徹底指南

ZGC是從JDK11中引入的一種新的支持彈性伸縮和低延遲垃圾收集器，ZGC能夠工做在KB~TB的內存之下，做爲一種併發的垃圾收集器，ZGC保證應用延遲不會超過10毫秒(即使在堆內存很大的狀況下)，在JDK11中是以實驗階段的特性被髮布出來的，到JDK13時，ZGC能夠支持到16TB的堆內存，而且能夠將未提交的內存歸還給操做系統。

爲何引入ZGC

JVM的自動垃圾收集雖然減小了開發人員的工做，在必定程度上減小了內存泄漏的風險，可是因爲GC是自動進行的，一些沒法預知的事情有時候可能產生對應用有害的影響。

• 延遲增長致使應用的吞吐量和性能

隨着時代發展，硬件會逐漸便宜，應用使用的內存將會愈來愈大，可是又不能增長延遲，下降吞吐量

ZGC保證，無論在什麼狀況下，延遲不會超過10毫秒。

The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:

• Pause times do not exceed 10ms
• Pause times do not increase with the heap or live-set size
• Handle heaps ranging from a few hundred megabytes to multi terabytes in size

ZGC特性

ZGC最典型的特性是它是一款併發(concurrent)的GC，其它的特性以下：

• 它能夠標記內存，複製和遷移(relocate)內存，全部的操做都是併發的，同時它有一個併發的引用處理器
• 其它的垃圾收集器都是使用store barriers，ZGC使用load barriers，用於跟蹤內存
  • lock->unlock->read->load 讀內存
  • use->assign->store->write 寫內存
• ZGC能夠更加靈活的配置大小和策略，相比於G1，它能夠更好的處理很是大(very large)對象的釋放
• ZGC只有一代，沒有新生代，老年代什麼的，可是ZGC能夠支持局部壓縮，在內存恢復和遷移(reclaim and relocate)時，ZGC仍然有很高的性能
• ZGC依賴NUMA-aware(非均衡存儲器訪問)，須要咱們的內存支持這種特色

特性進度表

• JDK11，2018年 9月
  • ZGC發佈
  • 不支持類的卸載。-XX:+ClassUnloading 不生效
• JDK12 2019年 3月
  • 支持併發的類卸載
  • 暫停時間進一步縮短
• JDK13 2019年 9月
  • 最大堆內存從4TB -> 16TB
  • 支持歸還未使用的內存 uncommitting unused memory
  • 支持Linux與/AArch64平臺
  • 減小時間到一個固定的時間點之下 (Reduced Time-To-Safepoint)
  • 支持 -XX:SoftMaxHeapSize ，當設置這個參數的時候，ZGC會盡可能在指定的內存大小之下，除非爲了不內存溢出：參考：bugs.openjdk.java.net/browse/JDK-…
• JDK 14 計劃在2020年3月
  • 增長穩定性
  • 支持不連續的地址空間
  • ...

ZGC支持的平臺：

平臺	是否支持	當前進度
Linux/x64	Y	Since JDK 11
Linux/AArch64	Y	Since JDK 13
macOS		In Progress
Windows		In Progress

垃圾收集原理

幾個術語：

• parallel 多個垃圾收集線程在一塊兒工做，應用可能會中止
• serial 垃圾收集器只有一個線程在工做
• stop the world 應用程序中止
• concurrent 垃圾收集器在後臺運行，應用程序同時也在運行
• incremental 在垃圾收集工做結束以前，先中止垃圾收集，等一會再過來完成剩下的工做

ZGC引入了兩個新的概念，pointer coloring和load barriers.

Point Coloring

這個特性讓ZGC可以發現，標記，定位和從新映射對象，它只能工做在64位的操做系統上，實現colored pointer須要虛擬地址(virtual address masking)。

• finalizable 對象能夠被finalizer到達
• marked0 和marked1 標記可達的對象
• remap 引用指針到當前對象的地址，對象可能會被relocate，這個地址表示對象被relocate

Load Barrier

load barrier是一段代碼，當線程從堆中加載引用的時候被運行。例如，當咱們訪問對象的一個非主要類型的屬性。

在ZGC中，load barrier檢查引用的元數據位，根據元數據位對引用的對象作一些處理，所以可能在咱們獲取對象的時候對象的引用會被修改掉，可是不影響咱們的使用。

實戰

能夠從jdk官網下載最新版本的JDK，下載地址：

www.oracle.com/technetwork…

快速開始

GC日誌標記格式以下：

-Xlog:<tag set>,[<tag set>, ...]:<log file>
複製代碼

只是想要查看ZGC是否生效：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc
複製代碼

想要查看更加詳細的ZGC日誌信息：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc*
複製代碼

將更詳細的日誌信息記錄在文件中：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc*:gc.log
複製代碼

GC調參

通用GC選項	ZGC選項	ZGC 診斷選項-XX:+UnlockDiagnosticVMOptions
-XX:MinHeapSize, -Xms -XX:InitialHeapSize, -Xms -XX:MaxHeapSize, -Xmx -XX:SoftMaxHeapSize -XX:SoftRefLRUPolicyMSPerMB	-XX:ZAllocationSpikeTolerance -XX:ZCollectionInterval -XX:ZFragmentationLimit -XX:ZMarkStackSpaceLimit -XX:ZPath -XX:ZUncommit -XX:ZUncommitDelay	-XX:ZProactive -XX:ZStatisticsInterval -XX:ZVerifyForwarding -XX:ZVerifyMarking -XX:ZVerifyObjects -XX:ZVerifyRoots -XX:ZVerifyViews

是否啓用NUMA支持：

# 啓用NUMA
-XX:+UseNUMA 

# 停用NUMA
-XX:-UseNUMA 
複製代碼

調整併發的線程數：

-XX:ConcGCThreads=
複製代碼

返回未提交的內存到操做系統，堆內存不會地址設置的最小堆內存-Xms

# 多久未提交的內存會返回給系統
-XX:+ZUncommit  -XX:ZUncommitDelay=<seconds>
複製代碼

開啓大分頁，通常會帶來更好的性能提高，吞吐量，延遲和啓動時間都有所改善。並無看到明顯的缺點

• 大分頁在Linux系統中通常爲2MB的大小，若是有16G的堆內存，那麼意味着須要16GB/2MB = 8192個大分頁，如下命令須要 Linux kernel >= 4.14

# 配置操做系統中的分頁池數量
echo 9216 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# 查看系統中如今的分頁數量
cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages


-XX:+UseLargePages
複製代碼

• 若是Linux kernel < 4.14，那麼以下方式

mkdir /hugepages
mount -t hugetlbfs -o uid=123 nodev /hugepages 
java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xms16G -Xmx16G -XX:+UseLargePages
複製代碼

開啓透明分頁，透明分頁可能致使延遲上的一些問題，有時候不推薦使用，開啓透明分頁須要Linux kernel < 4.7

# 開啓透明分頁
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled


-XX:+UseTransparentHugePage
複製代碼

最後

ZGC仍然是處於試驗特性階段，但其保證延遲時間不低於10ms的特性，以及當前對堆內存大小的支持力度，仍是值得一試，讓咱們期待ZGC成爲一款更加優越的垃圾收集器吧。

參考

• OpenJDK Wiki
• ZGC 介紹
• JDK11 之ZGC