串行与并行垃圾回收器的核心区别在于GC线程数量及用户线程是否能同时运行：两者均全程STW，但串行仅用单线程（如Serial），并行启用多线程（如Parallel Scavenge）压缩停顿时间，目标均为高吞吐量。

串行和并行垃圾回收器的核心区别，不在于“快或慢”，而在于“用几个线程干活”以及“用户线程是否能同时运行”。两者都全程暂停应用（STW），但并行靠多线程压缩停顿时间，串行则只用一个线程慢慢清理。

执行线程数量不同

串行 GC（如 Serial、Serial Old）全程只启用一个 GC 线程；并行 GC（如 Parallel Scavenge、Parallel Old、ParNew）会启动多个 GC 线程协同工作。

• Serial：哪怕机器有 16 核，也只用 1 个线程做标记、复制、整理
• Parallel：可通过 -XX:ParallelGCThreads=N 指定线程数，默认通常为 CPU 核心数
• ParNew 是 Serial 的多线程翻版，但只作用于新生代，老年代仍可能用 Serial Old

目标导向明显不同

串行适合资源受限的轻量场景，并行专为吞吐量优化设计。

• 串行：单线程无切换开销，在小内存、单核或客户端模式（Client VM）下反而更稳，JDK 早期默认
• 并行：牺牲部分响应性，换取更高吞吐量（用户代码运行时间 / 总时间），适合后台批处理、定时任务等
• 两者都不改善单次停顿的“尖峰感”，只是并行让这个尖峰变短些

STW 行为完全一致

这是关键共性：无论串行还是并行，GC 过程中所有用户线程都会被强制暂停，直到回收完成。

• 不是“并行=不卡”，而是“卡得更快”——比如串行停 200ms，并行可能停 80ms
• 初始标记、最终标记、对象移动等阶段仍需 STW，只是并行把这些阶段的耗时摊到多个线程上
• 若追求真正低延迟（如 Web API），必须转向并发类收集器（G1、ZGC），它们允许用户线程与 GC 线程“抢着跑”

典型配置与适用场景

选哪个，主要看硬件条件和业务需求。

• -XX:+UseSerialGC：嵌入式设备、小型工具类程序、开发测试环境
• -XX:+UseParallelGC（默认开启 Parallel Old）：中大型服务端应用，CPU 核心充足，关注日均处理量
• -XX:+UseParNewGC + -XX:+UseConcMarkSweepGC（已废弃）曾是过渡组合，现推荐直接用 G1 或 ZGC