gc线程是守护线程，因其仅服务用户线程、不承担业务逻辑，且jvm规定无非守护线程时立即退出，故必须设为守护线程以确保及时终止。
GC 线程是守护线程，根本原因在于它的角色定位和 JVM 的退出机制——它不承担业务逻辑，只在后台为用户线程服务；一旦所有用户线程结束，它就失去存在意义，JVM 会立即终止，不会等待它完成。
GC 的职责决定它必须是后台服务型
垃圾回收器的任务是自动清理不再使用的对象，释放堆内存。这项工作全程由 JVM 自动调度，开发者无法直接启动或控制 GC 线程。它不执行应用程序代码，也不响应外部请求，纯粹是支撑性基础设施。这种“只服务、不主导”的属性，天然契合守护线程的定义。
JVM 退出规则要求 GC 不能阻碍程序终止
JVM 的退出条件非常明确：只要没有用户线程在运行，JVM 就立刻退出。如果 GC 线程是非守护线程，哪怕主线程和所有业务线程都已结束，它仍可能处于标记、清除或压缩阶段，导致 JVM 无法关闭。这会造成资源滞留、进程僵死等问题。将其设为守护线程，就能确保：用户线程一结束，GC 线程被 JVM 强制中断，整个进程干净收尾。
实际运行中，GC 线程确实表现得像守护线程
你可以通过调试或工具验证这一点：
- 用 jstack 查看正在运行的线程，GC 相关线程（如 "G1 Young Generation"、"Concurrent Mark-Sweep Thread"）的 daemon 字段均为 true；
- 写一个只启动 GC 线程（比如调用 System.gc()）但无其他用户线程的程序，程序会瞬间退出，GC 不会真正执行；
- 所有主流 JVM 实现（HotSpot、OpenJ9、Zing）均将 GC 线程默认设为守护线程，这是 JVM 规范层面的统一设计，不是可选配置。
这不是权宜之计，而是架构级的设计选择
守护线程机制本身就是为了容纳这类“生命周期依附于业务线程”的后台任务。GC 线程只是最典型的一个例子，其他如 JVM 内部的编译线程（C2 CompilerThread）、监控线程（JMX Agent）等，也都是守护线程。它们共同构成 JVM 的“隐形骨架”，默默支撑用户线程运行，又绝不拖慢退出节奏。
