单线程Executor中父子任务共用同一执行器会触发逻辑死锁：唯一工作线程执行父任务时调用get()等待子任务，而子任务因队列积压无法被调度，导致永久阻塞。
在单线程 Executor（如 Executors.newSingleThreadExecutor() 或核心数为1的 ThreadPoolExecutor）中，父子任务共用同一执行器时，极易触发“逻辑死锁”——并非传统意义上的资源互斥死锁，而是任务调度层面的永久阻塞。
为什么单线程池特别危险？
单线程池只有1个活跃工作线程，且该线程必须顺序执行队列中的所有任务。一旦父任务在执行过程中调用 submit().get() 等待子任务完成，就形成不可解的闭环：
- 当前唯一线程正在运行父任务
- 子任务被提交进同一线程池的队列，等待该线程空闲后执行
- 但父任务卡在
get()上，不退出、不释放线程，子任务永远得不到执行机会 - 整个线程池实质“假死”，后续所有任务均无法启动
典型错误代码模式
以下是最常踩坑的写法：
❌ 错误示例（单线程池 + 同步等待）ExecutorService pool = Executors.newSingleThreadExecutor();<br>pool.submit(() -> {<br> System.out.println("父任务开始");<br> Future<?> child = pool.submit(() -> System.out.println("子任务应在此执行"));<br> child.get(); // ⚠️ 此处永久挂起<br> System.out.println("父任务结束");<br>});
运行后只会输出“父任务开始”，程序卡住，jstack 可见该线程处于 WAITING (on object monitor) 状态，等待自己提交的任务。
根本原因：违反执行模型假设
单线程 Executor 的设计前提是“任务之间无同步依赖”。它不支持“当前任务阻塞等待自己提交的另一个任务”这种递归式调度。这与 ForkJoinPool 的工作窃取或多线程池的资源冗余有本质区别——它没有备用线程可调度子任务，也没有内部机制打破等待链。
可靠解法：切断同步等待链
核心思路是让父任务不阻塞，而是以异步方式响应子任务完成：
-
用 CompletableFuture 链式编排：将子任务作为异步阶段提交，父逻辑通过
thenApply或thenAccept响应结果，完全避免get() - 换用 ForkJoinPool：即使设置并行度为1，其内部工作窃取机制仍允许子任务由同一线程“内联执行”，不会入队等待
- 分离线程池：父任务用单线程池，子任务交由另一独立线程池（哪怕仅2个线程），物理隔离资源竞争
- 改用 CallerRunsPolicy（慎用）：当队列满时由调用线程执行任务，可让子任务在父任务线程上直接运行，但会破坏异步语义，仅适合简单场景
