setdaemon(true) 的核心作用是将线程设为守护线程，使其不阻止jvm退出，仅在所有非守护线程结束时被强制终止；必须在start()前调用，否则抛illegalthreadstateexception；适用于监控、心跳等可丢失任务，不适用于需保证完成的资源清理或i/o操作。
Java 中 setDaemon(true) 的核心作用，是让线程成为 JVM 的“后勤人员”——它不决定程序生死，只在用户线程运行期间提供辅助支持。用对了很轻量，用错了会导致任务静默丢失、资源未释放、日志写不全等隐蔽问题。
必须在 start() 之前调用
这是最刚性的规则：线程对象创建后、尚未启动（即处于 NEW 状态）时，才能设置守护属性。一旦调用 start()，再执行 setDaemon(true) 就会抛出 IllegalThreadStateException。
- ✅ 正确顺序：
t.setDaemon(true); t.start(); - ❌ 错误写法：
t.start(); t.setDaemon(true);（运行时报错） - ⚠️ 注意：新线程默认继承父线程的守护状态。若从守护线程里新建子线程，它也是守护线程，除非显式调用
setDaemon(false)
适合做什么：无状态、可中断、允许丢失的任务
守护线程的生命周期由 JVM 自动管理，退出时不保证任何清理逻辑执行。因此它只适用于那些“做不完也无所谓”的后台工作：
- 周期性监控（如内存使用采样、线程数统计）
- 心跳上报（服务存活信号，丢一次不影响整体可用性）
- 软引用对象清理（GC 配合行为，非强依赖）
- 临时文件扫描（如清理过期 .tmp 文件，不保证删尽）
- 日志异步刷盘（注意：仅限缓冲区已落盘或可丢弃的日志）
绝对不能做什么：涉及资源释放或数据持久化的操作
因为 JVM 终止时会直接终止守护线程，不等待、不通知、不执行 finally 块或 shutdown hook：
- ❌ 文件写入（可能造成文件损坏或内容截断）
- ❌ 数据库事务提交（事务可能未真正提交）
- ❌ 网络连接关闭（socket 可能未正常 close，导致 TIME_WAIT 积压）
- ❌ 持有锁后退出（可能引发其他线程死锁）
- ❌ 依赖 finally 释放资源（
finally不会执行）
线程池场景下的常见误解
很多人想用 setDaemon(true) 控制整个线程池的行为，但这是无效的：
- ❌
new ThreadPoolExecutor(...).setDaemon(true)——ExecutorService接口没有该方法，调用会编译失败 - ✅ 正确做法：自定义
ThreadFactory，在newThread(Runnable r)中创建线程并设为守护线程 - ⚠️ 注意：即使线程池中的线程是守护线程，只要线程池本身被持有（如未 shutdown），它仍可能阻止 JVM 退出 —— 因为线程池内部维护的阻塞队列、worker 线程等可能产生隐式用户线程引用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
