zgc能通過并發執行垃圾回收實現亞毫秒級停頓，適用于低延遲場景。其優勢體現在三方面：1.極致低停頓，幾乎全部gc工作與應用線程并行，僅極短階段需stw；2.支持大堆內存，可高效管理數百mb至數tb堆內存且停頓時間不隨堆增大而增加；3.解決內存碎片問題，采用壓縮式設計消除碎片，確保長期運行穩定性。啟用zgc需關注maxheapsize、linux hugepages、reservedcodecachesize等參數，并結合監控工具分析性能。但zgc并非萬能，對于追求吞吐量最大化、堆內存較小、jdk版本受限或內存資源緊張的場景可能不是最佳選擇。
在Java里，要讓那些對響應時間敏感的應用跑得更順暢，ZGC（Z Garbage Collector）無疑是一個非常強勁的選項。它通過幾乎不中斷應用線程的方式來完成垃圾回收，將停頓時間控制在亞毫秒級別，這對于需要極致低延遲的服務來說，簡直是救星。
解決方案
啟用ZGC來優化Java低延遲應用性能，核心就是讓jvm使用這個革命性的垃圾收集器。最直接的方法，就是在啟動Java應用時，簡單地加上一個JVM參數：-XX:+UseZGC。
說實話，剛開始接觸ZGC的時候，我總覺得這么簡單的配置，真的能帶來那么大的提升嗎？但實際測試下來，尤其是在內存使用量大、對象創建銷毀頻繁的場景，ZGC的表現確實讓人眼前一亮。它不像G1或cms那樣，在某些階段需要較長時間的STW（Stop-The-World）停頓，ZGC的大部分工作都是并發進行的。它通過指針著色（Colored Pointers）和讀屏障（Load Barriers）等機制，讓應用線程和GC線程幾乎可以同時運行，即便是在處理TB級別的堆內存時，也能保持極低的停頓。這就像給你的應用打通了一條高速公路，雖然偶爾會有交警在路邊指揮交通（輕微的CPU開銷），但車流基本不會停下來。
立即學習“Java免費學習筆記（深入）”；
ZGC的優勢體現在哪些方面？它真的能做到亞毫秒級停頓嗎？
是的，ZGC確實能做到亞毫秒級停頓，而且這并不是一個理論值，在很多生產環境中都得到了驗證。它的優勢主要體現在幾個方面：
首先，極致的低停頓時間。這是ZGC最核心的賣點。它之所以能做到這一點，是因為它將幾乎所有的GC工作都設計成并發執行的。無論是標記、重定位還是引用處理，大部分時間都和應用線程并行。只有非常短的階段（比如初始標記和最終標記的一小部分）需要STW。這種設計對于那些對延遲極度敏感的系統，比如在線交易、實時廣告競價、高頻交易等，簡直是量身定制。我記得以前為了優化GC停頓，我們嘗試過各種參數調優，甚至不惜犧牲一些吞吐量，但效果總是不盡如人意。ZGC的出現，讓這些困擾迎刃而解。
其次，強大的大堆支持能力。ZGC可以高效管理從幾百MB到數TB的Java堆內存，而且其停頓時間幾乎不隨堆大小的增加而增加。這意味著，你可以為你的應用分配一個巨大的堆，從而減少GC的頻率，同時又不用擔心長時間的GC停頓。這對于內存密集型應用，比如大數據處理、緩存服務等，提供了極大的靈活性。你不再需要為了避免GC停頓而小心翼翼地控制內存使用，或者頻繁地進行分代調優。
當然，ZGC對內存碎片問題的解決也相當徹底。它是一個壓縮式（compacting）的垃圾收集器，這意味著它在回收內存的同時會整理內存，消除內存碎片。這對于長期運行的應用來說非常重要，因為內存碎片會導致無法分配大對象，進而觸發更頻繁的GC，甚至OOM。ZGC通過并發重定位（Concurrent Relocation）解決了這個問題，確保了堆內存的連續性。
啟用ZGC后，還需要關注哪些JVM參數或系統配置？
雖然ZGC本身已經非常智能，但啟用它之后，我們仍然需要關注一些相關的JVM參數和系統配置，以確保它能發揮最佳性能：
一個很關鍵的參數是MaxHeapSize。ZGC通常傾向于更大的堆內存。給ZGC更多的空間，它就能更從容地進行并發操作，減少GC的頻率。如果你把堆設置得太小，ZGC可能反而會因為頻繁觸發GC而顯得不夠高效。通常，我會根據應用的實際內存使用情況，給它留出足夠的余量，比如，如果應用峰值內存使用是10GB，我可能會設置20GB或更多。
另一個值得考慮的是linux的HugePages（大頁內存）。對于大堆（幾GB以上）的Java應用，使用HugePages可以顯著減少TLB（Translation Lookaside Buffer）未命中，從而提升內存訪問性能。你可以通過-XX:+UseLargePages或-XX:+UseTransparentHugePages來啟用。不過，透明大頁（THP）在某些場景下可能會引入一些不穩定的因素，比如內存碎片化導致性能抖動，所以如果追求極致穩定，手動配置靜態大頁（vm.nr_hugepages）可能更穩妥一些。這需要系統管理員的介入，提前在操作系統層面配置好。
此外，ReservedCodeCacheSize雖然不是ZGC特有的參數，但它對任何Java應用都很重要。如果Code Cache溢出，JIT編譯會停止，應用性能會急劇下降。雖然ZGC不會直接導致Code Cache問題，但作為一個低延遲應用，你肯定不希望因為其他原因而引入不必要的性能瓶頸。我通常會把這個值設得大一些，比如256MB或512MB，以防萬一。
最后，監控是必不可少的。啟用ZGC后，你需要通過GC日志（-Xlog:gc*）或者JFR（Java Flight Recorder）來觀察它的實際表現。GC日志會詳細記錄ZGC的每次停頓時間、并發階段耗時等信息，這對于驗證優化效果、發現潛在問題非常有幫助。JFR則能提供更全面的運行時數據，幫助你深入分析應用的性能瓶頸。
ZGC并非萬能，它在哪些場景下可能不是最佳選擇？
盡管ZGC在低延遲應用中表現出色，但它并非適用于所有場景，也不是一個“銀彈”。了解它的局限性，能幫助我們做出更明智的選擇：
首先，對于純粹追求吞吐量最大化的應用，ZGC可能不是最優解。由于ZGC需要進行大量的并發操作，并且引入了讀屏障等機制，這會帶來一定的CPU開銷。這意味著，在某些極端吞吐量敏感的場景下，G1或者Parallel GC可能會提供更高的整體吞吐量，因為它們在GC時可能會更“粗暴”地停頓應用，但在非GC時間段內，應用可以全速運行。如果你對延遲完全不敏感，只關心每秒能處理多少請求，那么ZGC的這些額外開銷可能就顯得不劃算了。
其次，對于堆內存非常小（比如幾百MB）的應用，ZGC的優勢可能不明顯，甚至可能帶來額外的開銷。ZGC內部有其復雜的數據結構和算法，這些機制在處理小堆時，其固定開銷可能會相對于收益顯得更大。在這種情況下，G1或者更簡單的Serial/Parallel GC可能就足夠了，而且配置起來也更簡單。我個人經驗是，如果你的堆小于1GB，你可能需要仔細評估ZGC是否真的能帶來顯著收益。
再者，ZGC對JDK版本有要求。雖然從JDK 11開始引入，但它在后續版本（如JDK 15, 17, 18）中得到了大量的優化和改進，包括分代ZGC的引入。如果你還在使用較老的JDK版本，那么ZGC可能還不夠成熟，或者某些功能尚未完善。在生產環境中使用，通常建議選擇LTS版本中較新的ZGC實現。
最后，ZGC的內存占用可能會略高于其他GC。這主要是因為它需要額外的內存來存儲其內部的元數據、著色指針信息以及并發處理所需的緩沖區。對于內存資源極其緊張的環境，這可能需要納入考量。當然，對于大多數低延遲應用，為了亞毫秒級的停頓，這點額外的內存開銷通常是完全可以接受的。
總的來說，選擇ZGC還是其他GC，最終還是要回到你的應用場景和性能目標。沒有哪個GC是普適的，理解它們的優缺點，才能做出最適合你的決策。
