setdaemon(true)不能实现服务驻留，仅使线程成为守护线程，jvm在所有非守护线程结束后强制终止它；正确驻留需用非守护线程配合退出机制与shutdown hook。
Java 中 setDaemon(true) 并不能真正实现“服务驻留”，它只是让线程成为守护线程，作用是：当 JVM 中所有非守护线程结束时，JVM 自动退出，不会等待守护线程执行完毕。把它当作“后台服务常驻”手段，是常见误解。
守护线程的本质：随 JVM 退出而终止
守护线程（Daemon Thread）的设计初衷是为其他线程提供服务，比如垃圾回收、JMX 监控等。它的生命周期依附于 JVM —— 只要主线程和所有用户线程（非守护线程）结束，JVM 就会直接关闭，守护线程会被强制中断，不会获得优雅退出机会。
- 调用
thread.setDaemon(true)必须在thread.start()之前，否则抛IllegalThreadStateException - 主线程默认是非守护线程；新建线程默认继承父线程的 daemon 状态
- 即使守护线程正在执行
while(true)循环，只要其他非守护线程结束，它也会被立即终止
想让服务“驻留”，得靠非守护线程 + 合理退出机制
真正需要长期运行的服务（如 HTTP 服务器、消息监听器），必须由非守护线程承载，并主动控制生命周期。常见做法：
- 启动一个非守护线程，内部用
while(running)循环 + 阻塞操作（如ServerSocket.accept()、Queue.take()）维持活跃 - 配合
Runtime.getRuntime().addShutdownHook()注册钩子，在 JVM 关闭前做清理（如关闭连接、刷盘） - 提供外部信号（如监听 shutdown 端口、响应 SIGTERM）来安全设置
running = false
setDaemon 的合理使用场景
它适合做纯辅助性、无状态、可随时中断的任务：
- 定期清理临时文件的调度器（用
ScheduledExecutorService创建的线程池默认是守护线程） - 日志异步刷写线程（但需确保关键日志已落盘，不能依赖它完成最后 flush）
- 心跳上报、指标采集等不涉及业务一致性的后台任务
避免典型误用
以下写法看似“驻留”，实则不可靠：
Thread t = new Thread(() -> {
while (true) {
doWork();
sleep(1000);
}
});
t.setDaemon(true); // ❌ 错误：JVM 一退出，此线程立刻消失
t.start();
正确思路是：让它成为非守护线程，并配合主逻辑或 shutdown hook 控制退出时机。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
