CMS垃圾回收器线程配置需区分并发与并行阶段：ConcGCThreads控制并发标记/清除线程数，默认为(ParallelGCThreads+3)/4；ParallelGCThreads和ParallelCMSThreads控制初始标记、重新标记等STW阶段的并行线程数，后者默认值同前者计算方式；调优应依据GC日志中remark耗时及CPU使用率，避免线程数超过CPU核数。
CMS 收集器的并发线程数需分两部分配置：一是并发标记/清除阶段使用的线程数（ConcGCThreads），二是并行阶段（如初始标记、重新标记）使用的线程数（ParallelGCThreads 和 ParallelCMSThreads）。它们作用不同，不能混用。
ConcGCThreads：控制并发阶段线程数
该参数直接指定 CMS 在 并发标记 和 并发清除 阶段启用的 GC 线程数量。这些线程与用户线程同时运行，会争抢 CPU 资源。
- 默认值为
(ParallelGCThreads + 3) / 4（向下取整），通常约等于 CPU 核数的 25%； - 若 CPU 核数为 8，
ParallelGCThreads默认为 8，则ConcGCThreads默认为(8+3)/4 = 2； - 建议根据实际负载调整：高并发低延迟场景可适当提高（如设为 3~4），但不宜超过 CPU 核数的 1/3，否则用户线程明显变慢；
- 显式设置示例：
-XX:ConcGCThreads=3。
ParallelGCThreads 与 ParallelCMSThreads：影响并行阶段效率
这两个参数控制 CMS 中需要 STW 的阶段（初始标记、重新标记）的并行能力：
-
-XX:ParallelGCThreads=N：定义年轻代 ParNew 收集器的并行线程数，默认等于 CPU 核数；CMS 启用时，它也间接影响ParallelCMSThreads的默认值； -
-XX:ParallelCMSThreads=N：专用于 CMS 的并行阶段（主要是 remark），默认值为(ParallelGCThreads + 3) / 4； - 例如：8 核机器，
ParallelGCThreads=8→ParallelCMSThreads默认为 2；若想加快 remark，可设为-XX:ParallelCMSThreads=4； - 注意：
ParallelCMSThreads不影响并发标记/清除，只影响 remark 等 STW 阶段的并行度。
实际调优建议
线程配置不是越多越好，关键在于平衡停顿时间与吞吐量：
- 优先观察 GC 日志中的 remark 耗时 —— 若较长，可适度增加
ParallelCMSThreads； - 若应用响应抖动明显、CPU 使用率持续偏高，说明
ConcGCThreads过多，应减少； - 常见组合（16 核服务器）：
-XX:ParallelGCThreads=12 -XX:ConcGCThreads=4 -XX:ParallelCMSThreads=3； - 避免设置大于 CPU 核数：CMS 并发线程过多反而引发上下文切换开销，得不偿失。
配套必须参数
单独调线程数效果有限，需配合基础 CMS 启用和触发策略：
- 启用 CMS：
-XX:+UseConcMarkSweepGC（JDK 9+ 已废弃，仅限 JDK 8u 及更早）； - 确保年轻代使用 ParNew：
-XX:+UseParNewGC（JDK 8 默认开启）； - 控制触发时机：
-XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly，防止并发失败； - 启用并发 remark 加速：
-XX:+CMSParallelRemarkEnabled（默认开启，显式写出更清晰）。
