JVM垃圾回收线程是守护线程，不由Java线程调度器管理，而是由JVM基于内存状态和GC策略自主触发；其执行时机由分配失败、晋升失败、元空间告警等事件驱动，并通过不同同步模型实现多线程协作。
JVM 垃圾回收线程本身不参与常规的 Java 线程调度（即不走 Thread.suspend/resume 或线程优先级抢占逻辑），它由 JVM 内部基于内存状态、GC 策略和运行时反馈自主触发与协调，不是操作系统层面可调度的普通用户线程。
GC 线程的本质与归属
GC 线程是 JVM 启动时创建的守护线程（Daemon Thread），例如 Reference Handler、Finalizer，以及各垃圾收集器配套的专用线程（如 G1 的 G1 Young RemSet Sampling、ZGC 的 ZStat 线程等）。它们不归 Java 应用线程池管理，也不响应 Thread.yield() 或 setPriority() 调用。
- 这些线程在 JVM 生命周期内常驻，仅当 JVM 退出时随 daemon 属性自动终止
- 它们的执行时机不由开发者控制，而是由 JVM 的 GC 触发条件驱动（如 Eden 区满、元空间告警、堆使用率超阈值等）
- 多数 GC 线程运行在独立的 native 线程上，由 JVM 自行绑定到 OS 线程，不经过 Java 线程栈调度器
触发时机：谁决定“现在该 GC 了”？
不是定时器，也不是轮询，而是基于事件驱动的被动响应机制：
-
分配失败触发：当对象在 Eden 区分配失败（
allocate返回 null），JVM 立即发起 Minor GC（如 Serial、Parallel、G1 的 Young GC） - 晋升失败触发：Minor GC 后对象需晋升老年代，但老年代无足够连续空间 → 触发 Full GC 或并发标记启动（取决于收集器）
-
元空间/直接内存告警：Metaspace 达到
-XX:MetaspaceSize或-XX:MaxMetaspaceSize阈值，或ByteBuffer.allocateDirect()分配失败，可能触发类卸载或元空间 GC - 并发收集器的周期性检查：G1/ZGC/Shenandoah 会定期采样堆使用率、预测停顿时间，并在满足条件时主动启动并发标记阶段
多线程协作：如何避免 GC 线程之间抢资源？
不同收集器采用不同同步模型，核心目标是避免 STW（Stop-The-World）期间竞争，同时保障并发阶段数据一致性：
- 串行收集器（Serial）：单 GC 线程，无并发问题；STW 期间所有 Java 线程暂停，GC 线程独占 CPU
- 并行收集器（Parallel GC）：多个 GC 工作线程（默认 = CPU 核数），共享任务队列，通过 work-stealing 协作扫描年轻代；仍需全局 STW
-
并发收集器（CMS/G1/ZGC）：
- CMS 使用初始标记（STW）、并发标记（Java 线程与 GC 线程并发运行）、重新标记（短 STW）三阶段
- G1 将堆划分为 Region，GC 线程按区域分片处理；并发标记阶段依赖写屏障（Write Barrier）记录跨区引用变化
- ZGC 使用读屏障（Load Barrier）+ 颜色指针，在 Java 线程访问对象时实时处理转发，GC 线程几乎全程并发
不可控但可观测：怎么知道 GC 线程正在做什么？
虽然无法调度 GC 线程，但可通过以下方式观察其行为：
- 启用 GC 日志：
-Xlog:gc*,gc+heap=debug,gc+ref=debug:file=gc.log:time,tags,uptime（JDK 10+） - 查看线程堆栈：
jstack <pid>中识别以GCTaskThread、ConcurrentMarkSweepThread、ZWorker等命名的线程 - 监控 JMX 指标：
java.lang:type=GarbageCollector下的CollectionCount、CollectionTime、LastGcInfo - 使用
jstat -gc <pid>实时查看各代使用量、GC 次数与耗时
