serial old收集器是专为单核cpu、≤256mb老年代堆、短生命周期无交互场景设计的标记-整理算法老年代gc，适用于嵌入式、cms失败兜底及ci构建等极简环境，超出边界则stw风险陡增。
Serial Old 收集器不是“被淘汰的旧技术”，而是有明确适用边界的专用工具——它只在单线程可控、停顿可接受、资源极简的场景下才真正合适，超出这个边界就容易引发不可控的 STW 风险。
适用边界：三类硬性约束
Serial Old 的适用性由三个不可妥协的条件共同定义，缺一不可：
- 硬件层面：CPU 必须为单核，或明确禁止多线程调度（如嵌入式 SoC 的固定绑定核）；多核环境下启用 Serial Old 不仅无法提速，反而因线程闲置放大停顿感知
- 内存规模：老年代堆空间 ≤ 256MB（JDK8 及之前建议 ≤ 128MB）；超过该阈值时，标记-整理阶段的扫描与移动耗时呈非线性增长，512MB 堆下 Full GC STW 容易突破 300ms
- 应用模式：生命周期短（≤ 数分钟）、无实时交互（如 CLI 工具、构建脚本、离线数据转换）、或允许明确中断（如 IoT 设备固件升级期间的 Java 模块重启）
生产环境慎用：不是性能差，而是责任错配
线上服务禁用 Serial Old 的核心原因，不是它“慢”，而是它把 GC 责任完全转嫁给业务线程，且不具备弹性缓冲能力：
- 无法应对突发流量导致的老年代快速填满——Parallel Old 或 G1 可通过并发标记分摊压力，Serial Old 只能触发一次长停顿 Full GC
- 没有降级保护机制：CMS 失败后 fallback 到 Serial Old 是被动兜底，但主动配置为默认则等于放弃容错设计
- 监控信号失真：STW 时间直接等同于请求超时或熔断触发点，无法像 ZGC/G1 那样分离“标记耗时”与“暂停耗时”，不利于根因定位
替代方案选择逻辑
当发现系统接近 Serial Old 边界（如单核设备但堆升至 200MB），应按优先级切换：
- 仍需极简部署 → 改用 G1（-XX:+UseG1GC）并限制最大 GC 时间（-XX:MaxGCPauseMillis=50），G1 在小堆下线程数自动收敛，停顿更可控
- 已有 Server 模式且吞吐优先 → 切换至 Parallel Old（-XX:+UseParallelGC），多线程压缩老年代比 Serial Old 快 3–5 倍，且 STW 更稳定
- 调试/归因需求强 → 保留 Serial Old 但仅用于 离线压测或启动参数验证（如 -XX:+PrintGCDetails -XX:+UseSerialGC），不接入生产链路
例外场景：Serial Old 的合理存在位置
它仍在以下真实生产环节中发挥不可替代作用：
- CMS 回收失败兜底：JDK8 环境中 CMS 触发 Concurrent Mode Failure 后，JVM 自动启用 Serial Old 完成 Full GC，确保内存最终可回收（虽卡顿，但不死机）
- 固件级 Java 运行时：某工业网关设备使用精简版 OpenJDK，总 RAM 仅 512MB，其中 JVM 堆固定为 96MB，Serial/Serial Old 是唯一满足 ROM 空间与实时性要求的组合
- CI 构建节点中的临时任务：Gradle 执行 jacoco:report 时加 -XX:+UseSerialGC，排除 GC 干扰，使覆盖率统计结果更纯净、可复现
