单线程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（慎用）：当队列满时由调用线程执行任务，可让子任务在父任务线程上直接运行，但会破坏异步语义，仅适合简单场景