如何优化垃圾回收机制减少暂停时间？

减少GC暂停时间需从三方面入手：首选G1、ZGC或Shenandoah等低延迟回收器；其次优化代码，减少对象创建、使用对象池和高效数据结构；最后通过GC日志分析与JVM参数调优，合理设置堆大小及回收策略，实现“对症下药”。

减少垃圾回收的暂停时间，这事儿说起来，真不是一蹴而就的。要我说，核心思路就是‘知己知彼，对症下药’。我们得先搞清楚自己的应用到底是个什么脾气，再选个合适的GC策略，然后就是精细化地调整和优化，甚至从代码层面去规避不必要的内存开销。它本质上是一个系统工程，涉及JVM、应用代码乃至硬件配置的综合考量。

解决方案

我个人觉得，很多人一上来就想着调参数，但往往忽略了最根本的——应用本身。如果你的代码一直在疯狂地创建大量短生命周期对象，或者不小心留下了很多长生命周期的“僵尸”，那再好的GC算法也只能是治标不治本。所以，我的“解决方案”，其实更像是一个多维度的策略组合拳，它包括了三个核心层面：选择合适的GC算法、从应用程序层面优化内存使用，以及通过JVM参数调优和GC日志分析进行精细化管理。

首先，GC算法的选择是基石。不同的垃圾回收器，其设计哲学和目标就不同。有些追求吞吐量最大化，有些则致力于将暂停时间压到最低。这就像你开车，高速路上追求速度，市区里就得考虑红绿灯和拥堵。我们得根据应用对延迟的容忍度来做决策。

其次，也是我认为最容易被忽视，但效果往往最好的部分，就是应用程序层面的内存优化。JVM再智能，也无法改变你代码里对内存的“挥霍”。减少不必要的对象创建、及时释放不再使用的资源、选择更高效的数据结构，这些都能从源头上减少GC的工作量。这就像是源头治理，如果垃圾少了，清理起来自然就快。

最后，才是JVM参数的精细化调优和GC日志分析。这就像是给你的应用做体检和开药方。通过分析GC日志，我们可以清楚地看到GC发生的频率、持续时间、回收了多少内存，从而判断当前的GC策略是否合理，堆大小是否合适，甚至有没有内存泄漏的迹象。然后，根据这些诊断结果，再去调整JVM的各项参数，比如堆大小、新生代老年代比例、GC触发阈值等，才能真正做到“对症下药”，而不是盲目试错。

如何选择合适的垃圾回收器以最小化暂停时间？

说实话，选GC器这事儿，没有“万能药”。我的经验是，先从G1开始，它在大多数场景下都表现得相当均衡。如果G1的暂停时间仍然不能满足要求，再考虑ZGC或Shenandoah。

在JDK 8及更早的版本中，如果你追求低暂停时间，CMS（Concurrent Mark Sweep）曾是一个不错的选择，它通过并发标记和清除来减少应用暂停，但它有一些固有的问题，比如浮动垃圾、并发模式失败等，而且在后续版本中已被弃用。对于大多数应用，特别是在JDK 8上，ParallelGC（并行GC）是默认的，它更注重吞吐量，暂停时间相对较长。

到了JDK 9及更高版本，G1GC（Garbage-First Garbage Collector）成为了默认的垃圾回收器。G1的设计目标之一就是可预测的暂停时间。它将堆划分为多个区域（Region），并尝试优先回收那些垃圾最多（即回收效率最高）的区域，这也是其名称“Garbage-First”的由来。G1通过-XX:MaxGCPauseMillis参数，允许你设定一个期望的最大暂停时间目标，G1会尽力去满足这个目标，但请注意，这只是一个软性目标，并非绝对保证。G1在处理大堆内存（通常是数GB到几十GB）时表现出色，它通过增量式、并发的标记过程来减少Full GC的发生，从而降低了长时间暂停的风险。

如果你的应用对暂停时间的要求极其严苛，例如需要亚毫秒级的暂停，那么ZGC（Z Garbage Collector）和ShenandoahGC就值得考虑了。它们都是高度并发的垃圾回收器，大部分工作都与应用线程并行执行，暂停时间通常可以控制在10毫秒以内，甚至在一些场景下能达到1毫秒以下。ZGC在JDK 11中引入，Shenandoah则在JDK 12中成为标准。它们都采用了着色指针（Colored Pointers）和读写屏障（Load Barriers）等先进技术，以实现几乎不中断应用线程的垃圾回收。但需要注意的是，这些高级GC器可能会带来更高的CPU开销，并且它们的内存管理模型与G1等有所不同，可能需要更深入的理解和测试。我见过很多团队，盲目追求最新的ZGC或Shenandoah，结果发现自己的应用场景根本吃不消其额外的CPU开销，或者配置不当反而更糟。所以，在选择时，一定要结合实际的应用负载、堆大小以及对CPU和内存资源的容忍度来综合评估。

应用程序层面的内存优化有哪些实用技巧？

这块儿我觉得才是真正考验程序员功力的地方。很多人觉得GC是JVM的事儿，跟代码没关系，这简直是天大的误解。我曾经在一次性能优化中，仅仅通过调整几个核心业务逻辑中的集合使用方式，就让GC暂停时间下降了近一半，那感觉真是“四两拨千斤”。

Booltool

常用AI图片图像处理工具箱

140

查看详情

1. 减少对象创建：

   • 对象池（Object Pooling）： 对于那些创建成本高、使用频繁的对象（如数据库连接、线程、大型临时对象），可以考虑使用对象池来复用。这避免了频繁的创建和销毁，从而减轻了GC的压力。

   • 避免不必要的中间对象： 比如在字符串拼接时，如果操作次数较多，应使用StringBuilder或StringBuffer，而不是直接使用+操作符，因为后者会创建大量的临时String对象。

     // 不推荐：会创建大量中间String对象
     String result = "";
     for (int i = 0; i < 1000; i++) {
         result += String.valueOf(i);
     }
     
     // 推荐：只创建一个StringBuilder对象，效率更高
     StringBuilder sb = new StringBuilder();
     for (int i = 0; i < 1000; i++) {
         sb.append(i);
     }
     String result = sb.toString();

     登录后复制

   • 使用基本类型和数组： 尽可能使用int[]而不是List<Integer>，使用int而不是Integer。基本类型直接存储值，不涉及对象头开销，也避免了自动装箱/拆箱带来的额外对象创建。

   • 缓存： 对于计算结果固定且频繁访问的数据，可以进行缓存。这不仅减少了计算量，也避免了重复创建相同对象。

2. 管理对象生命周期：

   • 缩小对象作用域： 尽量将对象的声明放在最小的作用域内，这样对象在不再需要时就能更快地被GC识别并回收。局部变量优先于成员变量。
   • 及时释放资源： 对于文件流、网络连接、数据库连接等资源，务必在不再使用时通过close()方法或try-with-resources语句及时关闭。这些资源通常会持有其他对象，不关闭可能导致内存泄漏。
   • 弱引用/软引用： 在实现缓存机制时，可以考虑使用WeakReference或SoftReference。SoftReference引用的对象在内存不足时会被GC回收，适合实现内存敏感的缓存；WeakReference引用的对象在下一次GC时就会被回收，适合实现生命周期短暂的缓存。

3. 选择高效的数据结构：

   • 不同的数据结构有不同的内存占用和访问效率。例如，ArrayList通常比LinkedList更节省内存，因为LinkedList的每个节点都需要额外的对象开销来存储前后指针。
   • 对于需要存储大量原始类型数据的集合，可以考虑使用一些第三方库，如Trove或FastUtil，它们提供了针对基本类型的集合实现，可以显著减少内存开销。

如何通过JVM参数调优和GC日志分析来进一步减少暂停时间？

我个人觉得，GC日志分析就像是给JVM做体检。你不看日志，就不知道它到底“病”在哪里。我记得有一次，一个应用经常出现十几秒的卡顿，后来一看GC日志，发现是某个老年代对象迟迟无法被回收，导致了频繁的Full GC。通过JFR进一步分析，才定位到是一个缓存组件没有正确配置过期策略。

1. 启用并分析GC日志：

   • JDK 9+： 使用-Xlog:gc*。例如，-Xlog:gc*:file=gc.log会将所有GC日志输出到gc.log文件。
   • JDK 8及更早版本： 使用-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log。
   • 分析工具： GCViewer、GCEasy.io、JFR (Java Flight Recorder)。这些工具可以将原始的GC日志可视化，帮助我们理解GC事件的频率、持续时间、堆内存变化等关键指标。
   • 关注点：
     • Full GC的频率和持续时间： 如果Full GC频繁发生且持续时间长，这通常是严重的性能瓶颈，可能暗示堆内存设置不当或存在内存泄漏。
     • Young GC（Minor GC）的频率和持续时间： 频繁的Young GC但每次回收的内存量很小，可能意味着新生代太小；如果Young GC时间过长，可能新生代太大。
     • 晋升到老年代的对象数量： 如果大量对象过早地晋升到老年代，会加速老年代的填充，增加Full GC的风险。

2. JVM参数调优：

   • 堆大小设置：
     • -Xms<size>和-Xmx<size>：设置JVM堆的初始大小和最大大小。通常建议将两者设置为相同的值，以避免JVM在运行时频繁调整堆大小带来的额外开销。堆太小会导致频繁GC，堆太大则可能导致单次GC暂停时间过长，特别是Full GC。经验上，通常设置为物理内存的60%-80%。
   • 新生代大小设置：
     • -Xmn<size>：直接设置新生代大小。
     • -XX:NewRatio=<ratio>：设置老年代与新生代的比例，例如-XX:NewRatio=2表示老年代是新生代的2倍。新生代过小会导致对象过早进入老年代，增加老年代GC压力；新生代过大则可能导致Young GC时间过长。
   • G1垃圾回收器特有参数：
     • -XX:+UseG1GC：启用G1GC。
     • -XX:MaxGCPauseMillis=<milliseconds>：设置G1GC期望的最大暂停时间。G1会尽力满足这个目标，但这只是一个软性目标。
     • -XX:InitiatingHeapOccupancyPercent=<percent>：设置G1GC在堆占用达到多少百分比时启动并发标记周期。默认值通常是45%。如果并发标记启动太晚，可能导致并发模式失败，从而触发Full GC。适当调低可以更早地启动并发标记，减少Full GC风险。
   • ZGC/Shenandoah参数：
     • -XX:+UseZGC或-XX:+UseShenandoahGC：启用对应的GC器。
     • 这些先进的GC器通常不需要像G1那样进行大量细致的参数调优，它们的设计目标就是“开箱即用”并提供极低的暂停时间。主要的调优仍然是堆大小的设置。

在进行调优时，务必遵循“小步快跑，持续观察”的原则。每次只修改少量参数，然后运行应用，收集GC日志，进行分析，观察效果。切忌一次性修改大量参数，这样很难判断哪个改动带来了正向或负向影响。同时，也要警惕内存泄漏，即使GC算法再优秀，如果应用存在内存泄漏，堆内存也会持续增长，最终导致频繁的Full GC甚至OOM，每次Full GC都是漫长的暂停。

以上就是如何优化垃圾回收机制减少暂停时间？的详细内容，更多请关注php中文网其它相关文章！