parallelgcthreads参数主要控制年轻代并行标记与复制、老年代并行标记与压缩、g1 gc中young/mixed gc的evacuation等并行阶段的线程数；默认值按cpu核心数计算：≤8核时等于核数，＞8核时为8+(核数−8)×5/8；合理配置需权衡吞吐量与停顿时长，避免过高导致cpu争抢。
-XX:ParallelGCThreads 是 JVM 启动参数，用于显式设置并行垃圾收集器（如 Parallel GC、G1 GC 的部分并行阶段）在执行并行 GC 任务时使用的**操作系统级线程数**，它直接影响 GC 的并行吞吐能力。
它控制哪些 GC 阶段的线程数？
该参数主要影响以下需多线程并行执行的 GC 工作：
- 年轻代（Young Gen）的并行标记与复制（如 Parallel Scavenge 中的 evacuate、copy）
- 老年代（Old Gen）的并行标记与压缩（如 Parallel Old 的 mark-sweep-compact）
- G1 GC 中的并行 Young GC、Mixed GC 的部分阶段（如 Evacuation、Remembered Set 扫描、Ref Processing）
- 并非所有 GC 阶段都受其控制——例如 CMS 的并发标记是独立线程，ZGC/Shenandoah 的并发阶段也不依赖此参数
默认值怎么算？
JVM 会根据 CPU 核心数自动计算默认值，但逻辑因 JDK 版本略有差异：
- 在多数 JDK 8/11/17 中，默认值 = min(物理 CPU 核心数, 8)
- 当物理核心数 > 8 时，JDK 通常设为 8 + (CPU 核心数 − 8) / 2（向上取整），即随核心数增长但增速放缓
- 可通过
jstat -gc <pid></pid>或 GC 日志中的[Parallel GC Threads: N]确认实际生效值
如何合理配置？
盲目增大不一定提升性能，需结合应用特征和系统资源权衡：
- 若应用是 CPU 密集型且 GC 压力大（如频繁 Full GC、STW 时间长），可适当调高（如设为物理核心数的 75%~100%）
- 若机器同时运行多个 JVM 或其他 CPU 敏感服务，应预留线程资源，避免争抢（例如 32 核机器跑 2 个 JVM，各设为 12~14）
- 对于小堆（
- 建议配合
-XX:+PrintGCDetails -Xloggc:gc.log观察 GC 日志中 “GC pause” 和 “parallel time” 是否明显下降
注意事项
这个参数只对支持并行工作的 GC 生效：
- 对 Serial GC 无效（它强制单线程）
- 对 ZGC、Shenandoah 等低延迟 GC 无影响（它们使用固定并发线程模型）
- 不能超过系统可用的 OS 线程数上限；过度设置可能触发
java.lang.OutOfMemoryError: unable to create native thread - 与
-XX:ConcGCThreads（控制并发 GC 线程数，如 G1 的并发标记）互不干扰，需分别评估
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
