JVM GC日志不直接显示并行线程数，需通过-XX:+PrintFlagsFinal或JMX查看ParallelGCThreads实际值；该参数仅对Parallel GC生效，容器中必须显式设置以避免默认按宿主机核数误配。
JVM GC 日志本身不直接显示“并行线程数”，它反映的是实际执行 GC 的线程行为（如 STW 时间、吞吐量、GC 阶段耗时等），而并行线程数是通过 JVM 启动参数控制的——日志只是验证你设置是否生效、效果是否合理的关键依据。
怎么看当前生效的 ParallelGCThreads 值
不能靠 GC 日志反推线程数，但可以快速确认 JVM 实际采用的值：
- 启动时加参数：-XX:+PrintFlagsFinal，然后过滤：
java -XX:+PrintFlagsFinal -version 2>&1 | grep ParallelGCThreads - 运行中查 JMX：用 JConsole 或 VisualVM 连接 JVM，在 MBean > java.lang > Runtime > SystemProperties 或 GC 相关 MBean 中查看（部分版本支持）
- 看 GC 日志中的线索：若使用 Parallel GC（-XX:+UseParallelGC），日志中频繁出现多线程并发处理痕迹（如多个 GC 线程几乎同时完成 minor GC，且总耗时明显低于单线程估算值），说明并行已启用；但具体数量仍需以参数为准
怎么设置并行 GC 线程数
通过 -XX:ParallelGCThreads=N 显式指定，N 是正整数。该参数只对 Parallel GC（吞吐量优先收集器）有效。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 默认值按逻辑处理器数自动计算：≤8 核时取核数；＞8 核时 ≈ 8 + (ncpu − 8) × 5/8（例如 32 核 → 23 线程）
- 容器环境必须显式设置：Docker/K8s 中若限制
--cpus=2，JVM 默认仍按宿主机核数算，极易导致线程过剩、上下文切换飙升 - 设为 1 会退化成单线程（类似 Serial GC），仅用于调试，不推荐生产
怎么用 GC 日志验证线程数是否合理
开启详细 GC 日志（如 -Xlog:gc*:file=gc.log:time,uptime,pid,tags），重点关注以下指标：
- STW 时间是否稳定下降：增加线程数后，minor GC 的 pause time 明显缩短（如从 80ms → 45ms），说明收益存在
-
GC 吞吐是否下降：如果 total GC time 占比（
GCTimeRatio）显著升高，或 CPU 使用率持续超 90%，可能是线程过多引发争抢 - 是否存在“线程闲置”：日志中连续多次 minor GC 耗时相近且未随线程数增加而改善，说明已到收益拐点（比如 8 核设 12 线程，效果和设 8 一样）
常见误配与建议值参考
不是越多越好，也不是等于物理核数就最优：
- 纯 CPU 密集型服务（业务线程已占满 CPU），建议 ParallelGCThreads ≤ CPU 配额 × 0.7（留资源给业务）
- 批处理类应用（允许稍高延迟、追求吞吐），可设为 CPU 配额 × 1.2（上限不超过物理核数）
- 8 核容器限制下，设 -XX:ParallelGCThreads=6 往往比默认 8 更稳；32 核物理机部署单个 JVM，设 20～24 比默认 23 更易压测调优
- 切勿跨收集器混用：CMS 用 -XX:ConcGCThreads，G1/ZGC 有各自并发线程参数，
ParallelGCThreads对它们无效
