选Serial还是Parallel取决于应用对吞吐量和停顿时间的容忍度及硬件资源：Serial适合单核、小堆、轻量场景；Parallel适合多核、大堆、高吞吐后台任务。
选 Serial 还是 Parallel，关键看应用对吞吐量和停顿时间的容忍度，以及运行环境的资源约束。Serial 适合轻量、单核、小堆场景；Parallel 更适合多核、后台计算类任务，追求整体执行效率。
看硬件与部署环境
单核 CPU 或容器中被限制为 1 核时，Parallel 的多线程反而带来调度开销，实际 GC 效率可能低于 Serial。Serial 单线程无竞争，启动快、内存占用小，更适合嵌入式、边缘设备或小型工具类程序。
多核服务器环境下，Parallel 能充分利用 CPU 并行处理新生代回收，尤其当堆内存较大（比如 1GB 以上）、对象创建频繁时，吞吐优势明显。
- 容器中用
--cpus=1或cgroups限核 → 倾向 Serial - 物理机或云主机有 4+ CPU 核 → Parallel 更稳妥
- 堆初始值（
-Xms）和最大值（-Xmx）设为相同且 ≤200MB → Serial 完全够用
看应用类型与 SLA 要求
Serial 的 STW（Stop-The-World）虽不可避免，但小堆下通常仅几毫秒，对批处理脚本、CLI 工具、单元测试进程影响极小。而 Parallel 默认不控制单次停顿，只优化总吞吐——它可能让一次 Minor GC 耗时略长，但单位时间内完成更多用户任务。
立即学习“Java免费学习笔记（深入）”；
- 离线数据清洗、定时报表生成 → 选 Parallel（关注“1 小时内跑完多少任务”）
- 嵌入式网关、本地开发服务、Spring Boot 简易 demo → Serial 更轻量、更可预测
- 若明确要求“每次 GC 不超过 50ms”，Parallel 需配合
-XX:MaxGCPauseMillis=50调优，但可能牺牲吞吐
看配套老年代收集器是否匹配
Serial 必须搭配 Serial Old（单线程老年代），整套都是串行节奏；Parallel Scavenge 默认配 Parallel Old（多线程老年代），两者协同保障吞吐目标。不能混搭 ParNew + Parallel Old，也不能让 Parallel Scavenge 强制配 CMS —— HotSpot 不支持这类组合。
-
-XX:+UseSerialGC→ 自动启用 Serial + Serial Old -
-XX:+UseParallelGC→ 自动启用 Parallel Scavenge + Parallel Old（JDK8+ 默认行为） - 手动指定
-XX:+UseParallelOldGC已过时，JDK8 起 Parallel Scavenge 会自动选用 Parallel Old
简单验证方法
加参数 -XX:+PrintGCDetails -Xloggc:gc.log 启动后观察日志：
- 如果 GC 日志里频繁出现
DefNew（Serial 新生代）或PSYoungGen（Parallel 新生代），就能确认实际生效的收集器 - 对比两次运行：相同负载下，Serial 的 GC 次数可能略多但每次耗时短；Parallel 的 GC 次数少、单次耗时稍长，但总 GC 时间占比更低
- 用
jstat -gc <pid>查看YGCT（Young GC 时间）和FGCT（Full GC 时间），算出吞吐比例（1 - (YGCT+FGCT)/uptime）
