jvm在高并发下gc压力的核心矛盾是对象创建速率远超回收能力，导致年轻代快速填满、晋升加速、老年代承压加剧，引发频繁minor gc、过早full gc或长停顿；应对需从回收器选型（g1/zgc为主）、堆结构调优（固定堆大小、增大年轻代、控制大对象晋升）、代码层控对象生命周期（禁无界缓存、避高频大对象、启tlab）及监控闭环（gc日志、jstat、apm）三端协同。
JVM 在高并发下承受 GC 压力的核心矛盾是：对象创建速率远超回收能力，导致年轻代快速填满、晋升加速、老年代承压加剧，最终引发频繁 Minor GC、过早 Full GC 或长停顿。应对不是靠“扛”，而是从参数、回收器、代码三端协同控制压力源头和释放路径。
选对回收器：按延迟与堆大小匹配
默认 Parallel GC 适合吞吐优先场景，但高并发下停顿不可控；CMS 已被弃用，且易因并发失败触发 Full GC。当前主流选择有：
-
G1 GC：适用于堆内存 ≥8GB、P99 停顿需控制在 100ms 内的中大型服务。它通过 Region 分区实现可预测停顿，支持混合回收（同时清理新生代+部分老年代），关键参数如
-XX:MaxGCPauseMillis=100、-XX:InitiatingHeapOccupancyPercent=45可主动触发并发标记，避免突发性老年代满。 -
ZGC：适用于对延迟极度敏感（如支付、实时推荐）、堆 ≥16GB 的服务。其亚毫秒级停顿源于并发标记+并发转移+着色指针机制，全程几乎无 STW。启用只需
-XX:+UseZGC，配合-Xmx设置合理上限即可，无需调优年轻代比例。 - 小堆（≤4GB）且延迟要求宽松时，仍可考虑 CMS 的历史替代方案（如 Shenandoah），但生产环境建议优先验证 G1 或 ZGC。
调优堆结构：稳住年轻代节奏
高并发下对象“朝生夕死”特征明显，年轻代配置不当会直接放大 GC 压力：
- 设
-Xms与-Xmx相等（如-Xms12g -Xmx12g），避免运行时扩容带来的额外开销和碎片。 - 增大年轻代占比：用
-Xmn显式指定（如总堆 12GB 时设-Xmn4g），或通过-XX:NewRatio=2控制老/新比例。目标是让 Eden 区能容纳峰值请求周期内产生的临时对象，减少 Minor GC 频次。 - 控制大对象直接入老年代：设
-XX:PretenureSizeThreshold=1048576（1MB），使超过该阈值的对象绕过年轻代，避免复制开销；但需确认这类对象生命周期确实较长，否则会加速老年代耗尽。 - 缩短对象晋升年龄：对长期驻留的大缓存对象，可设
-XX:MaxTenuringThreshold=0，使其首次 GC 就进入老年代，省去多次复制——前提是这些对象不会短期淘汰。
管住对象生命周期：从代码层减负
再好的 GC 参数也救不了失控的对象分配：
- 禁用全局静态集合无限制缓存（如
static Map存全量数据），改用带过期策略的Caffeine或Guava Cache，避免老年代被长生命周期对象占满。 - 避免在高频路径（如接口入口、定时任务）中创建大对象：JSON 解析不用
String中转，改用流式解析；批量处理改分页或抽样，防止一次申请数百 MB 内存。 - 启用 TLAB（Thread Local Allocation Buffer）：
-XX:+UseTLAB（默认开启），减少多线程竞争 Eden 区指针，提升分配效率。 - 检查并清理未关闭的资源引用（如数据库连接、文件句柄），防止间接导致对象无法回收。
监控闭环：用数据驱动调优
不看日志和指标的调优等于盲调：
- 加参数开启详细 GC 日志：
-Xlog:gc*,gc+heap=debug,gc+ergo*=trace:file=/var/log/gc.log:time,tags,level（JDK11+），重点观察Pause Young间隔与耗时、晋升量（promotion字段）、老年代占用趋势。 - 用
jstat -gc PID 1000实时查看各代使用率与 GC 次数，发现 Eden 持续高位或老年代缓慢上涨，往往是缓存泄漏或晋升异常信号。 - 结合 APM 工具（如 SkyWalking、Arthas）定位 GC 高峰时段的热点方法，判断是业务逻辑问题还是配置不足。
