串行与并行回收器本质区别在于是否启用多线程参与GC，均STW但线程数与优化目标不同：串行单线程省资源适合小堆单核，並行多线程提吞吐适合多核大堆。
串行与并行执行机制，本质区别在于是否启用多线程参与垃圾回收，直接影响停顿时间、吞吐量和适用场景。
串行回收器：单线程 STW，简单可控
Serial（新生代）和 Serial Old（老年代）都采用单线程工作模式，全程触发 Stop-The-World —— 应用线程全部暂停，直到 GC 完成。
- 新生代用复制算法：把存活对象从 Eden 或 From 区复制到 To 区，过程快、无碎片，适合对象朝生暮死的场景
- 老年代用标记-整理算法：先标记所有存活对象，再将它们紧凑地移动到一端，消除内存碎片，但移动开销比标记-清除大
- 启动开销小，不依赖额外线程资源，适合单核 CPU、桌面应用或小型服务（如几十 MB 堆内存）
- 可通过 -XX:+UseSerialGC 显式启用，此时年轻代和老年代均使用串行收集器
并行回收器：多线程加速，追求吞吐量
Parallel Scavenge（新生代）和 Parallel Old（老年代）是典型的“吞吐量优先”组合，同样采用 STW，但利用多个线程并行执行回收任务。
- 新生代仍用复制算法，但由多个线程协作扫描 Eden 和 Survivor 区，缩短单次 Minor GC 时间
- 老年代用标记-整理算法，多线程并行完成标记与整理阶段，相比 Serial Old 显著减少 Full GC 停顿
- 适用于多核服务器环境，尤其关注单位时间内处理任务量（如批处理、后台计算类应用）
- 默认在 Server 模式下启用（JDK 8+），也可通过 -XX:+UseParallelGC 明确指定
关键差异不在“并发”，而在“线程模型与目标取舍”
串行与并行都不与用户线程并发执行，都存在 STW；区别不是“能不能并发”，而是“用几个线程干活”以及“为谁优化”：
立即学习“Java免费学习笔记（深入）”；
- 串行：省资源、低延迟波动、适合轻量级场景，但堆稍大时停顿明显
- 并行：压榨多核性能、提升整体吞吐，但单次 GC 停顿仍较长（只是比串行短），不适合对响应时间敏感的服务
- 两者都不解决“长时间卡顿”问题——那是 CMS、G1、ZGC 等并发/增量式回收器的设计目标
如何选择：看硬件配置和业务特征
没有绝对优劣，只有是否匹配实际运行条件：
- 单核 CPU 或堆 ≤ 100MB → Serial GC 更稳，避免线程调度开销
- 多核 + 堆 1GB~8GB + 吞吐优先（如定时报表、ETL）→ Parallel GC 更合适
- 若需控制最大停顿时间（如 Web API 接口），则应跳过串行/并行，考虑 G1 或 ZGC
- 可通过 -XX:+PrintGCDetails -Xloggc:gc.log 观察实际 GC 日志，对比 Minor GC/Full GC 的耗时与频率再决策
