Parallel GC不适合高并发场景，因其STW停顿长、无并发标记、易触发频繁Minor GC和秒级Full GC；推荐G1（可控停顿）、ZGC（≤10ms）或Shenandoah（低CPU开销）替代。
Parallel GC 不适合应对高并发下的 GC 回收风暴。它不是为低延迟、高对象分配速率的在线服务设计的，强行用于 Web API、实时计算或事件驱动类系统，反而会放大停顿、加剧 Full GC 风险，导致响应超时甚至雪崩。
为什么 Parallel GC 在高并发下容易失控
高并发场景中，请求密集、对象“朝生夕死”、分配速率高、要求尾延迟稳定（如 P99 ≤ 50ms），而 Parallel GC 的行为与之天然冲突：
- 每次 Minor GC 都是 Stop-the-World，且默认不约束单次停顿——流量高峰时可能每秒触发多次，累积停顿显著侵蚀有效运行时间
- 自适应策略（-XX:+UseAdaptiveSizePolicy）会动态压缩年轻代以满足吞吐目标，结果是 Eden 更小、GC 更频繁，进一步抬升线程调度开销
- Parallel Old 没有并发标记阶段；一旦短命变量因 Survivor 溢出或大对象直接进入老年代，触发 Full GC，停顿可达数秒
- 无内存预测与区域化回收能力，无法像 G1 那样按需清理部分老年代 Region，面对突发流量缺乏弹性
更合理的替代方案选择
若 JDK 版本允许（JDK 8u20+ 推荐 G1；JDK 11+ 强烈考虑 ZGC；JDK 12+ 可选 Shenandoah），应直接切换收集器：
- G1 GC：用 -XX:MaxGCPauseMillis=50 显式约束停顿目标，自动分 Region 回收，兼顾吞吐与可控延迟，适配大多数 Spring Boot/WebFlux 类服务
- ZGC：JDK 11 起可用，停顿基本恒定在 10ms 内，支持 TB 级堆，特别适合变量高频读写、强 SLA 要求的实时风控或网关节点
- Shenandoah：并发标记 + 并发整理，CPU 占用比 ZGC 略低，对资源受限但延迟敏感的容器化部署更友好
如果必须保留 Parallel GC（如受限于 JDK 7/8 且无法升级）
需严格规避常见误操作，并做保守配置：
- 关闭自适应策略：-XX:-UseAdaptiveSizePolicy，防止 JVM 动态劣化 SurvivorRatio 或压缩新生代
- 禁用 -XX:MaxGCPauseMillis——该参数在 Parallel 下会误导 JVM 过度收缩堆，反而引发更频繁 GC
- 设固定堆大小：-Xms4g -Xmx4g（按压测峰值内存占用上浮 20% 设定），避免扩容抖动
- 增大老年代比例：-XX:NewRatio=3（即老年代:新生代 = 3:1），并确保 Survivor 区足够（如 -XX:SurvivorRatio=8），减少晋升压力
- 监控对象晋升速率，若发现大量对象在年龄
比换 GC 更有效的根本解法
真正缓解 GC 压力，关键不在参数，而在降低对象生成压力：
- 用对象池复用高频短命对象（如 Netty 的 PooledByteBufAllocator、Jackson 的 ObjectReader/ObjectWriter 缓存）
- 避免在请求链路中创建大临时集合（如 List<Map> 嵌套结构），改用流式处理或预分配容量
- 将可复用的上下文对象（如 RequestContext、TraceContext）设为 ThreadLocal + 复用，而非每次 new
- 检查 JSON 序列化/反序列化是否重复构造 ObjectMapper 实例，应全局单例 + 配置复用
