SingleThreadExecutor在线程异常终止后不会重启旧线程，而是下次提交任务时新建线程继续执行；其底层ThreadPoolExecutor（corePoolSize=maxPoolSize=1）在worker异常退出后调用addWorker()创建全新线程，ID和名称均变化，且仅对未捕获异常触发重建。
SingleThreadExecutor 不会“重置”已死亡的线程，而是在线程因未捕获异常终止后，**下次提交任务时新建一个线程**来继续执行队列中的任务。这不是重启旧线程，也不是主动恢复，而是一种按需重建的保障机制。
线程死亡后不复用，只新建
它的底层是 ThreadPoolExecutor（corePoolSize = maxPoolSize = 1，空闲超时为 0），当工作线程因 RuntimeException 或 Error 未被捕获而退出时：
- 当前线程对象彻底结束，JVM 回收其资源
- 线程池不会尝试唤醒或复用它
- 下一次调用
submit()或execute()时，触发addWorker()，创建一个全新线程 - 新线程 ID、名称均不同，可通过
Thread.currentThread().getId()验证
必须让异常“真正杀死线程”
只有未捕获的异常才能触发重建。如果在任务中自行 try-catch 并吞掉异常，线程会继续存活，但逻辑可能出错：
- ✅ 正确触发重建：直接抛出
throw new RuntimeException("oops") - ❌ 不触发重建：用
try { ... } catch (Exception e) { /* 忽略 */ } - ⚠️ 注意：
submit(Callable)包装的任务即使抛异常，也不会杀线程——异常被封装进 Future，线程继续运行
如何确保顺序不中断地持续执行
依赖 SingleThreadExecutor 的自动重建能力时，还需注意两点：
立即学习“Java免费学习笔记（深入）”；
- 任务必须用
execute()或submit(Runnable)提交；若用submit(Callable)，异常不传播，线程不死，但业务失败可能被静默掩盖 - 避免在任务中调用
System.exit()、Runtime.getRuntime().halt()或 OOM 级错误，这些会导致 JVM 级崩溃，无法重建 - 如需更细粒度控制（比如记录每次重建），可继承
ThreadPoolExecutor，重写afterExecute检查t != null判断是否发生了异常终止
比 newFixedThreadPool(1) 更可靠的原因
两者都只用一个线程，但行为关键不同：
-
newSingleThreadExecutor()：线程挂了 → 下个任务自动建新线程 → 队列继续消费 → 顺序保得住 -
newFixedThreadPool(1)：线程挂了 → 没有兜底重建逻辑 → 后续所有任务永久阻塞在队列里 → 服务实际失效 - 前者还通过
FinalizableDelegatedExecutorService封装，禁止调用setCorePoolSize()等破坏单线程语义的操作
