setDaemon 方法的核心价值不在于增强系统稳定性，而在于精准界定线程的退出边界；守护线程本质上是附属型线程，JVM 仅依据非守护线程是否存活进行判断，误用会导致任务丢失、静默下线；正确的做法是将监控、保活这类后台任务设为守护线程，以此隔离核心业务的生命周期。
首先澄清一个关键点：setDaemon 本身并不会直接提升系统稳定性，恰恰相反，使用不当反而容易引发意外退出、任务丢失，甚至资源泄漏。它的真正价值在于——让你能够精准控制线程的退出边界，从而使稳定性设计变得更加可控。
守护线程不是稳定器，而是退出开关
Java 的守护线程本质上是“附属型”的，它不参与 JVM 存活判定。只要所有非守护线程结束，JVM 就会立刻终止，所有守护线程一并中断——不会执行 finally，不会触发 shutdown hook，也不会等待 I/O 完成。
- 如果把关键任务误放在守护线程里，后果就是服务在你还未察觉的情况下静默下线——心跳还没发完，日志还没刷盘，everything 就停了。
- 主线程设为守护线程？main() 一返回，JVM 瞬间退出，子线程根本没机会启动。
- 守护线程 spawn 的新线程默认也是守护线程——调度器停了，所有任务线程被集体终结。
真正支撑稳定性的是“分层生命周期管理”
setDaemon 的正确用法，是把后台辅助任务（比如监控上报、连接保活、异步刷盘）明确划归为“可随时丢弃”的角色，从而隔离核心业务线程的生命周期。
- 主服务逻辑、请求处理、事务提交等必须跑在非守护线程中（包括线程池里的工作线程）。
- 日志异步写入线程设为守护线程——主流程不受其阻塞影响，但需要确保缓冲区有落盘兜底机制。
- 健康检查线程设为守护线程——它只反映状态，不决定服务存续；真正决定是否存活的是业务线程是否活跃。
必须守住的硬性规则
以下几条，违反任何一条，稳定性设计都会失效：
- setDaemon(true) 调用有严格的时间窗口：必须在 new 出线程之后、start() 之前调用。启动之后再设，JVM 会直接抛 IllegalThreadStateException 异常。
- 守护线程里创建的新线程默认继承守护属性——如果确实需要派生持久任务，必须显式调用 t.setDaemon(false)。
- ExecutorService 无法通过 API 设置守护属性——需要自定义 ThreadFactory，在 newThread() 中手动设置 daemon 状态。
- JVM 退出时不会等待守护线程——所有依赖“自然结束”的清理逻辑（比如 close()、flush()）必须前置，或者由非守护线程兜底。
和外部稳定性工具协同才完整
Java 层面的守护线程只作用于 JVM 内部生命周期。要想实现真正的系统级服务稳定性（比如崩溃自动重启、开机自启、资源隔离），还需要结合：
- OS 层服务包装器（如 systemd service、Java Service Wrapper）
- 进程看护机制（supervisord、docker restart policy）
- 应用内健康探针 + 外部负载均衡器主动摘流
setDaemon 是内部线程治理的一环，不是系统可用性的全部答案。
