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是普适的，理解它们的优缺点，才能做出最适合你的决策。
