cms低延迟、并发执行，仅初始和重新标记stw；parallel高吞吐、全程stw，高并发下易卡顿。cms已废弃，新项目推荐g1或zgc。
CMS 和 Parallel 在高并发请求场景下的响应表现差异明显，核心在于它们的设计目标和停顿策略不同。
CMS 专为低延迟设计，适合高并发 Web 服务
CMS 的目标是把单次 GC 停顿时间压到最短，这对响应敏感型系统很关键。它采用并发标记清除算法，大部分阶段（如并发标记、并发清理）能和用户线程一起跑，只在初始标记和重新标记两个环节短暂 STW（通常几毫秒）。这意味着在流量高峰时，应用仍能持续处理请求，接口 P99 延迟波动小，用户体验更平稳。
但要注意：
- 并发阶段会占用 CPU 资源，高并发下若 CPU 已接近满载，可能拖慢业务线程
- 无法处理“浮动垃圾”，且标记-清理会产生内存碎片，老年代碎片多了容易触发 Full GC，反而造成长停顿
- CMS 在 JDK 9 中被标记为废弃，JDK 14 后彻底移除，新项目不建议选用
Parallel 专注吞吐量，高并发下可能引发明显卡顿
Parallel 是吞吐量优先的收集器，新生代和老年代回收都全程 STW。虽然多线程并行加快了回收速度，但每次 GC 都会让所有业务线程暂停。在高并发请求持续涌入时，频繁或稍大的 GC（尤其是老年代回收）会导致请求堆积、超时、TPS 下降。比如一个 200ms 的老年代 GC，就等于整台机器在这段时间内完全不响应新请求。
不过它也有适用情况：
- 请求模型偏批处理、非实时（如定时报表生成），允许短时不可用
- 系统 CPU 资源充裕，且堆内存配置合理（如年轻代足够大，避免过早晋升）
- 通过
-XX:MaxGCPauseMillis可设目标停顿时长，但 JVM 会以牺牲吞吐量为代价去满足，可能导致更频繁的小 GC
实际选型看业务 SLA 要求
- 如果接口平均响应要求
- 如果后台任务为主，关注单位时间完成请求数，可接受偶尔 100~300ms 停顿 → Parallel 更稳、参数简单、成熟可靠
不复杂但容易忽略：GC 行为最终取决于堆大小、对象生命周期、晋升频率等实际负载特征，光选对收集器不够，必须配合合理的内存分代设置和监控验证。
