在系统的高并发运行阶段，如果某个 API 的平均响应时间从几十毫秒偶尔飙升至接近 1 秒，并且在监控面板上呈现出规律的锯齿状波动，这种现象往往与底层资源的周期性消耗有关。
遇到此类性能抖动，除了排查数据库慢查询和网络延迟外，熟悉 Java 虚拟机的工程师通常会考虑另一个因素：JVM 频繁触发的新生代垃圾回收（Young GC，简称 YGC）引发的 Stop-The-World（STW）停顿。本文将探讨一次典型的由大对象频繁创建引发的 YGC 抖动问题及其优化思路。
内存消耗源头：大尺寸报告对象
通过获取应用运行时的 JVM Dump 文件并使用 MAT（Memory Analyzer Tool）进行分析，我们定位到了导致内存快速消耗的对象：一份包含多维常模比对矩阵的心理报告实体类。
当大量用户在相近时间点请求生成或查看报告时，业务线程为了完成数据组装，会在内存中实例化结构复杂的嵌套 JSON 报告对象。这些对象体积偏大，在极高并发的催化下，新生代（Young Generation）的 Eden 区会在极短时间内被填满。
Eden 区空间耗尽会导致 JVM 执行 YGC，在此期间应用线程会被暂停（STW）。尽管单次 YGC 停顿可能只持续几百毫秒，但在海量请求涌入的高峰期，短暂的停顿就会导致 HTTP 请求排队、超时，进而影响整体服务稳定性。
内存层面的优化：引入对象池复用
减少垃圾回收压力的有效途径之一，是降低内存分配的速率。针对那些构建成本高且占用空间大的对象，橙星云技术团队在业务逻辑中采用了对象复用策略。
我们引入了 Apache Commons Pool2 库，针对算分上下文及报告生成过程中的核心大对象建立了一个“对象池”。当业务线程需要拼装报告时，不再直接通过 new 关键字分配新内存，而是从池中获取一个已有的对象实例。完成数据计算并输出响应后，对该对象进行数据清理，并将其归还到对象池中。
通过这种复用机制，大幅减少了在 Eden 区产生临时大对象的数量，从而有效降低了 YGC 的触发频次。
JVM 运行参数的针对性调整
在代码逻辑优化的基础上，结合服务器的物理内存规格调整 JVM 启动参数也是必不可少的环节。原有的默认参数可能对新生代的划分偏保守，难以应对突发的大对象分配。
我们可以对 JVM 参数进行适度调整，例如：
“`bash
-Xms4g -Xmx4g -Xmn2g
显式扩大新生代（Xmn）的空间比例，为存活时间短的大对象提供充足的缓冲区
-XX:+UseG1GC
启用 G1 垃圾回收器，替代传统的回收算法
-XX:MaxGCPauseMillis=50
设定期望的最大垃圾回收停顿时间
“`
通过合理配置新生代内存配比，结合 G1 垃圾回收器的 Region 分区特性，可以更好地控制单次 GC 的停顿时间。在系统面临压力测试或真实的业务洪峰时，业务代码层的优化与 JVM 底层参数调优相配合，是保障后端服务响应速度和平稳运行的有效手段。