高并发下jvm gc优化核心是提升可预测性与轻量性，首选g1收集器并设停顿目标（如-xx:maxgcpausemillis=50），合理分配堆大小与分代比例，规避晋升风暴，结合应用层减少对象创建。
高并发场景下，JVM 垃圾回收（GC）容易成为性能瓶颈——年轻代快速填满、频繁 Young GC，甚至触发不可控的 Full GC，导致请求延迟飙升或服务卡顿。优化核心不是“减少 GC”，而是让 GC 更可预测、更轻量、更贴合业务节奏。
优先选用 G1 收集器并设定停顿目标
G1 是目前高并发生产环境的主流选择，尤其适合堆内存大于 4GB 的服务。它把堆划分为多个 Region，能按需回收垃圾最多、空间最空的区域，从而在大堆下仍控制停顿时间。
- 启用 G1：
-XX:+UseG1GC - 明确停顿目标（关键！）：
-XX:MaxGCPauseMillis=50（建议设为 20–100ms，根据 SLA 调整） - 避免默认的“尽力而为”行为：G1 会据此动态调整新生代大小、并发线程数和回收频率
合理分配堆与分代比例
堆太大不等于性能好；堆太小又易频繁 GC。重点在于匹配对象生命周期特征：
- 初始堆与最大堆保持一致：
-Xms4g -Xmx4g，避免运行时扩容抖动 - 新生代不宜过大（如超过堆的 60%）：否则 Young GC 扫描范围过大，单次耗时上升；也不宜过小（如低于 25%）：导致对象过早晋升老年代，加重 Mixed GC 压力
- G1 下推荐显式控制：
-XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=50
规避晋升风暴与内存泄漏
高并发下常见问题是短生命周期对象因 Survivor 区过小或年龄阈值过低，直接晋升老年代，引发 Mixed GC 频繁甚至 Full GC。
- 观察 GC 日志中
Age分布和Promotion Failure记录 - 适当增大 Survivor 区占比：
-XX:SurvivorRatio=6（即 Eden:Survivor = 6:1:1） - 限制晋升年龄：
-XX:MaxTenuringThreshold=6，避免过早晋升 - 配合监控工具（如 jstat、Prometheus + JVM Exporter）识别长期存活对象，排查缓存未清理、静态集合滥用等内存泄漏点
配合应用层做协同优化
JVM GC 不是孤立环节。高并发系统需从代码和架构层面减轻 GC 压力：
- 复用对象：使用对象池（如 Netty 的
ByteBuf池）、ThreadLocal 缓存临时对象 - 减少临时对象生成：避免在循环内创建字符串拼接、包装类、Stream 中间操作等
- 异步写日志、批量处理消息：降低单位时间对象创建速率
- 线程池配置与 GC 协同：避免线程数过多导致栈内存占用高、GC Roots 扫描变慢
