守护线程是JVM退出语义与看门狗职责对齐的底层契约，它不参与JVM存活判定，仅依附业务线程生命周期，在所有用户线程结束后自动终止，确保微服务快速启停、零残留下线。
守护线程不是“可选优化”，而是实现非业务侵入式看门狗的底层契约。它之所以成为现代高阶微服务框架中的唯一红线，根本原因在于：JVM 的退出语义与看门狗的职责本质必须严格对齐——看门狗不能拖住系统下线，也不能在系统存活时失能。
看门狗必须依附于业务生命周期，而非反向绑定
微服务强调快速启停、滚动更新和故障隔离。若看门狗用普通线程实现，它会成为独立存活单元：即使所有业务线程（如 Spring Boot 的 DispatcherServlet 线程、Netty EventLoop、Quarkus Vert.x 事件循环）已优雅关闭，只要看门狗线程还在轮询或等待超时，JVM 就无法退出。这直接破坏了容器编排（K8s liveness/readiness probe）、CI/CD 自动发布和灰度回滚等关键流程。
而守护线程天然满足这一约束：它不参与 JVM 存活判定，只在业务线程运行期间提供支撑。一旦主服务实例完成 shutdown hook、清空线程池、释放连接，守护线程自动终止——无需显式 stop()、interrupt() 或 awaitTermination()，零耦合、零残留。
心跳续约类逻辑只能放在守护线程中安全执行
以 Redisson 分布式锁的看门狗为例：它需周期性向 Redis 发送 EXPIRE 命令延长锁过期时间。这个操作：
- 不能阻塞业务线程（否则影响接口响应）
- 不能持有事务上下文或 MDC 日志链路（否则污染业务追踪）
- 不能依赖 Spring 容器生命周期（否则在 ContextClosedEvent 后仍尝试刷新 Bean）
- 不能触发 finally 或 shutdown hook（JVM 终止时不执行，强行写会导致 NPE 或连接泄漏）
只有守护线程能同时满足全部四点。它的线程上下文干净、无 Spring 代理、无事务传播、无资源强引用，且 JVM 退出时直接回收栈帧——恰好匹配“续约是尽力而为，失败即释放”的分布式锁设计哲学。
多级异常检测必须由守护线程统一承载
高阶框架的看门狗不止喂狗，还要监控线程死锁、CPU 毛刺、堆外内存泄漏、gRPC 流挂起等。这些检测若分散在各模块中，必然引入：
- 重复采样开销（多个线程同时读 /proc/pid/status）
- 状态竞争（多个线程修改共享 health flag）
- 启动/停止时序混乱（A 模块先注册检测，B 模块后初始化，但 B 先销毁）
一个集中式守护线程可封装完整检测流水线：按优先级轮询指标 → 聚合异常等级 → 触发分级响应（告警 / 降级 / 强制重启）。它本身不参与业务调度，却能全局感知；不持有业务对象，却能反射获取线程栈和 JVM 运行时数据——这种“旁观者视角”正是非侵入性的核心。
红线之所以是“唯一”，因替代方案均违反架构原则
有人试图用 ScheduledExecutorService + 自定义 ThreadFactory 替代，但问题明显：
- 线程池默认创建非守护线程，需手动 setDaemon(true)，且必须在 newThread() 中完成，稍有疏忽就变成阻塞 JVM 退出的“幽灵线程”
- 线程池 shutdown() 需显式调用，而微服务 shutdown 流程中常因 Bean 销毁顺序错乱导致该调用被跳过
- ThreadPoolExecutor 的 beforeExecute/afterExecute 会混入业务线程上下文，破坏隔离性
也有方案将看门狗嵌入 Netty ChannelHandler 或 Spring Interceptor，但这已属业务侵入：它依赖特定框架、污染调用链、无法跨语言（如 Java 服务调用 Go 微服务时失效）。唯有守护线程是 JVM 层原语，与框架无关、与语言无关、与部署形态无关——这才是真正意义上的“基础设施级看门狗”。
