首先需要明确：JVM 垃圾回收线程的调度并不依赖固定优先级，而是由 JVM 根据回收器类型、系统资源和当前 GC 阶段动态协调。默认情况下，GC 线程与普通应用线程同级别（优先级 5），不会主动抢占 CPU。只有在 STW（Stop-The-World）阶段，所有应用线程被暂停，GC 线程才能不受限制地执行。实际运行中，它还受到操作系统调度、当前负载以及容器环境的影响。
那么，JVM 垃圾回收器的工作线程调度机制究竟如何运作？实际上，整体策略由 JVM 根据回收器类型、系统资源及当前 GC 阶段进行动态协调，而非依赖某个固定的优先级列表。
回收线程默认不主动抢占CPU资源
大多数垃圾回收线程（例如 CMS、G1 的并发标记线程）默认运行在中等优先级，通常与普通应用线程同级——Java 线程优先级 5。这意味着它们不会主动抢占 CPU，JVM 也不会将 GC 线程设为最高优先级而影响业务响应。关键要点包括：
- STW 阶段：所有应用线程被强制暂停，GC 线程执行不受调度限制，能够全力运转。
- 并行回收器（如 Parallel GC、ParNew）：采用多线程并行，线程数默认等于 CPU 核心数，不会无限提升并发度。
- 并发回收器（如 G1、ZGC）：后台线程（如并发标记、引用处理）通常以守护线程方式运行，调度由操作系统决定，JVM 仅负责启动与协调。
不同回收器对线程调度的处理策略差异
线程调度策略因回收器设计目标不同而有显著差异：追求吞吐量的回收器倾向于充分利用 CPU，低延迟回收器则更注重控制 GC 线程的执行节奏。
- ParNew / Parallel GC：新生代回收采用多线程并行执行，线程数可通过
-XX:ParallelGCThreads=N显式指定，默认值与 CPU 核心数相同，适用于多核服务器。 - G1 GC：混合使用并行（如 Young GC）与并发线程（如并发标记）。并发线程数默认按公式
max(1, (CPU核心数 × 8) / 5)计算，也可通过-XX:ConcGCThreads参数调整。 - ZGC / Shenandoah：几乎所有 GC 工作均并发执行，线程调度高度依赖操作系统，JVM 仅负责启动和协调，不干预线程优先级。
实际调度受运行时环境因素制约
即便设置了线程数或目标并发度，最终执行效果仍受限于操作系统调度器、CPU 负载、内存带宽等实际条件。正所谓计划赶不上变化——
- 当系统负载高、CPU 繁忙时，并行 GC 线程可能被操作系统降低调度频率，导致 GC 时间延长。
- 容器环境下（如 Docker），若未配置 CPU quota 或 shares，JVM 可能误判可用核心数，导致线程数过多或过少。
- 部分回收器（如 Serial GC）完全单线程，不涉及线程调度问题，仅适用于极简场景。
调优建议：关注实际效果，而非强行提升优先级
有些开发者试图通过修改线程优先级来“加速 GC”——这种做法通常无效甚至有害。真正有效的做法是使回收器行为与业务特征相匹配。
- 切勿手动调用
Thread.setPriority()干预 GC 线程，JVM 内部线程不允许外部修改优先级。 - 在高吞吐场景下可适当增加
-XX:ParallelGCThreads，但上限建议不超过 CPU 核心数 × 1.5。 - 延迟敏感型服务优先选用 ZGC 或 Shenandoah，再配合
-XX:+UseLargePages减少 TLB 压力，间接提升调度效率。 - 监控
GCTimeRatio和 GC 暂停时间分布，比纠结线程优先级更能定位真实瓶颈。
