jvm垃圾回收线程调度不依赖固定优先级，而是由jvm根据回收器类型、系统资源和gc阶段动态协调；默认与应用线程同级（优先级5），不抢占cpu，仅stw阶段无调度限制，实际执行受os调度、负载及容器环境约束。
JVM 垃圾回收器的工作线程调度不依赖固定优先级，而是由 JVM 根据回收器类型、系统资源和当前 GC 阶段动态协调。
回收线程默认不抢占 CPU 主动权
多数垃圾回收线程（如 CMS、G1 的并发标记线程）默认运行在低优先级线程中，通常与普通应用线程同级（Java 线程优先级 5），不会主动抢占 CPU。JVM 不会将 GC 线程设为最高优先级，避免影响业务响应。
- 仅在 STW（Stop-The-World）阶段，所有应用线程被强制挂起，此时 GC 线程执行不受调度限制
- 并行回收器（如 Parallel GC、ParNew）会启用多线程，但线程数默认等于 CPU 核心数，而非无限拉高并发度
- 并发回收器（如 G1、ZGC）的后台线程（如并发标记、引用处理）通常以守护线程方式运行，调度由操作系统决定
不同回收器对线程调度的处理差异
线程调度策略因回收器设计目标而异：追求吞吐量的回收器倾向“用足 CPU”，而低延迟回收器更注重控制 GC 线程的执行节奏。
-
ParNew / Parallel GC：新生代回收使用多线程并行执行，线程数可通过
-XX:ParallelGCThreads=N显式设置；默认值为 CPU 核数，适用于多核服务器 -
G1 GC：混合使用并行（如 Young GC）与并发线程（如并发标记），其并发线程数默认为
max(1, (CPU核心数 × 8) / 5)，可调参-XX:ConcGCThreads - ZGC / Shenandoah：几乎所有 GC 工作都并发执行，线程调度高度依赖操作系统，JVM 仅负责启动和协调，不干预线程优先级
实际调度受运行时环境约束
即使设置了线程数或期望并发度，最终执行仍受限于 OS 调度器、CPU 负载、内存带宽等现实条件。
- 当系统负载高、CPU 忙碌时，并行 GC 线程可能被 OS 降低调度频率，导致 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 pause 时间分布，比纠结线程优先级更能定位真实瓶颈
