parallel old 收集器通过并行标记-整理算法与parallel scavenge协同实现高吞吐量，适用于批处理等后台任务：它压缩内存抗碎片、支持大对象分配，并依托gctimeratio和自适应调优动态保障gc时间占比≤1%，在4–10gb堆、多核服务器上稳定发挥优势。
Parallel Old 收集器在大吞吐量场景下发挥优势，核心在于它与 Parallel Scavenge 配合，形成一套“以总执行效率为优先”的闭环策略——不拼单次停顿短，而是让 JVM 在单位时间内尽可能多地运行用户代码。
并行标记-整理算法抗碎片、稳分配
老年代对象生命周期长、晋升频繁，容易产生内存碎片。Parallel Old 采用多线程并行的标记-整理（Mark-Compact）算法：先并发标记存活对象，再将它们向内存一端压缩，最后清理边界外空间。这种机制避免了碎片堆积，保障大对象能连续分配，减少因空间不足触发的额外 Full GC，间接提升吞吐稳定性。
- 相比 Serial Old 的单线程整理，Parallel Old 在 4–8GB 堆规模下 STW 时间仍可控，且随 CPU 核数增加线性加速
- 压缩后内存规整，后续晋升和大对象分配失败率显著降低，避免因频繁扩容或 Full GC 打断长周期计算
与 Parallel Scavenge 协同调控吞吐目标
Parallel Old 不是孤立工作的，它的价值在与 Parallel Scavenge 组成完整分代回收链时才充分释放。JVM 通过 -XX:GCTimeRatio=n 直接设定 GC 时间占比上限（如 n=99 表示 GC 总耗时 ≤1%），整个回收链会自动反馈调节：年轻代大小、晋升年龄、Survivor 比例等均由 -XX:+UseAdaptiveSizePolicy 动态优化，无需人工干预。
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 例如批处理任务持续运行数小时，JVM 会逐步扩大年轻代，减少 Minor GC 频次；同时延缓晋升，把更多对象在新生代内回收干净
- 老年代压力因此被平滑分摊，Full GC 触发间隔拉长，整体用户代码执行时间占比自然升高
适合堆中等、CPU 充足的后台型负载
它不是为超大堆（>16GB）或低延迟服务设计的，而恰恰匹配典型高吞吐场景的硬件与业务特征：4–12 核服务器、堆设为 4–10GB、任务可接受数百毫秒级 STW（如 ETL 跑批、报表生成、模型训练中间步骤）。
- 堆设为 -Xms = -Xmx，避免运行时扩容引发意外 Full GC，保障吞吐节奏稳定
- 线程数由 -XX:ParallelGCThreads 自动适配 CPU 核心数，4–8 核时默认即最优，无需调优
- 不建议强行压低 -XX:MaxGCPauseMillis，否则 JVM 会缩小年轻代换“短停顿”，反而增加 GC 次数，拖累吞吐
日志与监控聚焦吞吐达成度
判断它是否真正发挥优势，不看单次 GC 耗时，而看长期统计指标：GC 时间占总运行时间的比例是否稳定接近设定值（如 GCTimeRatio=99 → GC 占比 ≈1%），以及应用实际完成的任务量（如每分钟处理记录数、每小时产出报表份数）是否持续高位。
- 启用 -XX:+PrintGCDetails -Xloggc:gc.log，配合工具分析 GC 频次、吞吐率趋势，而非只盯某次 Pause 时间
- 若发现 Full GC 过于频繁，优先检查是否对象过早晋升（如 Survivor 区太小）、或存在内存泄漏，而非切换 GC 策略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
