serial是单线程、简单可靠、适合小堆单核的串行回收器;parallel是多线程、吞吐量优先、适配多核大堆的并行回收器,二者线程模型、设计目标、适用场景及配套老年代收集器均不同。

Serial 和 Parallel 是 JVM 中两种基础但定位差异明显的垃圾回收器,核心区别不在“能不能用”,而在于“为谁设计、在哪运行、追求什么”。
执行方式与线程模型不同
Serial 是单线程收集器,回收时只启用一个 GC 线程,所有工作串行完成;Parallel 则默认使用与 CPU 核数相等的多线程并行执行——比如 4 核机器上会启动 4 个 GC 线程同时扫描 Eden 区、复制存活对象。
- Serial 没有线程调度和同步开销,启动快、内存占用极小(适合几十 MB 堆)
- Parallel 多线程带来吞吐优势,但也引入锁竞争和上下文切换成本,在单核或被限制为 1 核的容器中反而可能比 Serial 更慢
设计目标根本不同
Serial 关注“简单可靠”,不设吞吐量或停顿时间目标;Parallel 明确以“吞吐量优先”为使命——它通过自适应调节策略(如动态调整新生代大小、Survivor 比例、对象晋升年龄)来最大化用户代码执行时间占比。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Serial 的 STW 时间虽不可控,但小堆下通常仅 1–5ms,对 CLI 工具、单元测试进程几乎无感
- Parallel 可能让某次 Minor GC 耗时略长,但单位时间内完成更多业务任务,适合批处理、ETL、科学计算等后台服务
适用场景有明确分界
选哪个不是看“新旧”,而是看部署环境和应用类型是否匹配。
- 单核 CPU、Docker 容器中设置 --cpus=1 或 cgroups 限核 → Serial 更稳
- 物理机/云主机有 4+ CPU 核、堆内存 ≥1GB、对象创建频繁 → Parallel 更合适
- 堆初始值与最大值设为相同且 ≤200MB(如 -Xms200m -Xmx200m)→ Serial 完全胜任
- 服务类应用需低延迟响应(如 Web API)→ 这两类都不推荐,应考虑 G1 或 ZGC
配套老年代收集器也不同
Serial 默认搭配 Serial Old(单线程、标记-整理),构成纯串行组合;Parallel 默认搭配 Parallel Old(多线程、标记-整理),形成全并行吞吐方案。JDK 8 中 Parallel Scavenge + Parallel Old 是默认组合。
- 不能混搭:-XX:+UseParallelGC 启用 Parallel Scavenge 后,老年代自动启用 Parallel Old,无需额外指定
- 若手动指定 -XX:+UseSerialOldGC,则强制老年代退回到 Serial Old,破坏吞吐一致性
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










