JVM垃圾回收线程数需匹配物理核心能力并依回收器类型、系统负载和容器环境动态调整：Parallel GC用ParallelGCThreads控制全并行阶段；G1分ParallelGCThreads（并行）与ConcGCThreads（并发）；ZGC/Shenandoah通常无需手动设置；超线程逻辑核不可直接等同物理核；多JVM或容器场景须结合cgroups限核后再设参；务必通过GC日志和jstat验证实际生效。
JVM 垃圾回收线程数不是填个 CPU 核数就完事，关键得让 GC 线程真正“跑得动”，又不跟业务线程抢资源。核心原则是：线程数要匹配物理核心能力，而非简单等于逻辑核总数；同时必须结合回收器类型、系统负载和容器环境动态判断。
看回收器类型决定线程角色
不同回收器对线程的依赖方式不同，不能一概而论：
- Parallel GC：全阶段并行，-XX:ParallelGCThreads 控制所有 Young GC 和老年代 GC 的工作线程数；默认值按公式计算（≤8核时=核数，＞8核时=8 + (核数−8)×5/8），但建议手动设为物理核心数或略低
- G1 GC：分并行与并发两套线程：-XX:ParallelGCThreads 用于初始标记、混合回收等并行阶段；-XX:ConcGCThreads 用于并发标记、清理等后台线程，默认约是前者的 1/4，一般不建议调高，否则挤占应用线程 CPU 时间
- ZGC/Shenandoah：几乎全程并发，GC 线程数由 JVM 自动管理，通常无需手动干预；强行调参反而可能破坏其低延迟设计
按物理核心数而非逻辑核设上限
超线程（Hyper-Threading）带来的逻辑核 ≠ 真实并行能力。尤其在高吞吐或内存密集型 GC 场景下，启用全部逻辑核易引发 L1/L2 缓存争用、TLB 压力上升，实际吞吐不升反降：
- 32 核物理 CPU（64 逻辑核）：ParallelGCThreads 设为 32 较稳妥；若系统还跑着高负载数据库或中间件，可压到 24～28
- 单机多 JVM 场景（如 Kubernetes Pod 内多个 Java 进程）：必须限制每个 JVM 的可用 CPU 数（如 cgroups 或 --cpus=2），再据此设 ParallelGCThreads，避免 128 核机器上单个 JVM 开出 80+ GC 线程，拖垮整机调度
验证是否真正生效
参数写了不等于起效，得靠日志和运行时数据确认：
- 加启动参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察 GC 日志中 “Using X parallel GC threads” 和 “Using Y concurrent GC threads” 字样
- 用 jstat -gc <pid> 查看 GC 线程实际参与次数，对比 CPU 使用率（如 top 中 %us 是否持续接近 100% 且无明显抖动）
- 若发现 GC 线程数达标但 CPU 利用率偏低，可能是 Eden 区太小导致 GC 频繁、对象晋升过快，或存在锁竞争抑制了并行效率，需结合堆分配速率和晋升率分析
结合任务特征动态权衡
线程数不是静态最优解，它随负载变化而漂移：
- 后台批处理（CPU 密集、允许停顿）：可适当提高 ParallelGCThreads，压榨吞吐，比如设为物理核数，配合 -XX:GCTimeRatio=99
- 在线 API 服务（延迟敏感）：优先保响应时间，宁可稍降吞吐；G1 下更应关注 -XX:MaxGCPauseMillis 目标，让 JVM 自动调节并发线程节奏，而非硬塞更多线程
- 容器化部署：必须通过 --cpus 或 CPU Quota 限定容器可见核数，否则 JVM 读到的是宿主机总核数，会导致线程数严重超标
