setdaemon(true)只能在线程new状态下调用，启动后调用会抛illegalthreadstateexception；因jvm需在调度初始化时确定守护语义，运行时修改会导致生命周期管理混乱和竞态问题。
因为 setDaemon(true) 只能在线程处于 NEW 状态 时调用，一旦线程已启动（即执行过 start()），其状态就不再是 NEW，此时再调用会立即抛出 IllegalThreadStateException。
setDaemon() 的调用时机限制
Java 规定守护线程属性必须在线程启动前确定。这是 JVM 的硬性约束，不是建议而是强制规则：
-
setDaemon()内部会检查线程当前状态，若getState() != Thread.State.NEW，直接抛出IllegalThreadStateException - 该检查发生在 native 层之前，不依赖线程是否真正运行，只要调用过
start()，状态就已变更 - 即使线程刚 start、run() 还没执行，甚至瞬间就结束了，状态也早已离开 NEW
为什么设计成这样？
守护线程的语义决定了它不能中途切换：
- JVM 靠线程的 daemon 标志决定“进程是否等待它结束”——这个决策在调度器初始化线程时就要确定
- 运行中动态改 daemon 属性会导致 JVM 无法一致管理生命周期，比如：主线程已准备退出，突然把一个正在跑的非守护线程改成守护，可能引发资源清理错乱
- 避免状态竞态：如果允许运行时修改，多线程环境下难以保证所有子系统（如线程组、安全管理器）同步感知变更
正确写法示例
必须在 start() 之前设置，且通常在构造后立即操作：
Thread t = new Thread(() -> {
System.out.println("I'm running");
});
t.setDaemon(true); // ✅ 正确：NEW 状态下设置
t.start(); // ✅ 启动
以下写法全部错误：
-
t.start(); t.setDaemon(true);→ 抛异常 -
new Thread(...).setDaemon(true).start();→ 表面可行，但链式调用不改变顺序，仍是先 set 再 start，合法；可读性差，不推荐 - 在
run()方法里调用setDaemon()→ 当前线程对象已是 RUNNABLE 或更高状态，必抛异常
替代思路：避免运行时修改
如果业务需要“按需决定是否守护”，应在创建线程前就明确策略：
- 用工厂方法封装：根据参数返回已设好 daemon 属性的线程实例
- 结合
ThreadFactory统一配置，例如在ExecutorService中通过自定义 factory 设置守护属性 - 不要试图捕获
IllegalThreadStateException来“兜底”——这说明代码逻辑本身违反了线程模型
