在异步编程实践中，存在一种极为隐蔽的死锁风险，它并非源于传统的锁资源竞争，而是由任务调度层面的设计缺陷所引发。具体而言，当开发者在一个单线程 Executor（例如通过 Executors.newSingleThreadExecutor() 创建，或核心线程数为1的 ThreadPoolExecutor）中，让父任务与子任务共享同一个执行器时，极易触发这种“逻辑死锁”。其本质在于：唯一的工作线程在执行父任务时，因调用 get() 方法而阻塞等待子任务完成，但子任务却因队列积压无法获得调度机会，最终导致程序永久阻塞。
为何单线程池风险更高？
根本原因在于其资源模型的特殊性。单线程池仅有一个活跃的工作线程，所有任务都必须在此线程上顺序执行。这构成了一个致命的闭环：
- 当前唯一的线程正在执行父任务。
- 父任务向同一个线程池的任务队列提交了一个子任务，等待该线程空闲后执行。
- 然而，父任务在提交子任务后，立即调用了
Future.get()方法，进入阻塞等待状态。 - 由于父任务尚未完成，它不会释放占用的工作线程，导致子任务永远无法被取出执行。
- 最终，整个线程池陷入“假死”状态，后续所有任务都无法得到调度。
典型的错误代码模式
以下代码是最具代表性的踩坑示例：
❌ 错误示例（单线程池 + 同步等待）
ExecutorService pool = Executors.newSingleThreadExecutor();
pool.submit(() -> {
System.out.println("父任务开始");
Future child = pool.submit(() -> System.out.println("子任务应在此执行"));
child.get(); // ⚠️ 此处将永久挂起
System.out.println("父任务结束");
});
运行这段代码，你只会看到输出“父任务开始”，随后程序便陷入停滞。使用 jstack 工具查看线程状态，会发现该线程处于 WAITING (on object monitor)，它正在等待一个由自己提交的任务——这是一个不可能完成的任务。
根本原因：违反执行模型的基本假设
单线程 Executor 的设计隐含了一个关键前提：任务之间不应存在同步依赖。它不支持“当前任务阻塞等待自身提交的另一个任务”这种递归式调度需求。这与 ForkJoinPool 的工作窃取机制，或多线程池的资源冗余特性有本质区别。单线程池没有备用线程来调度子任务，其内部也缺乏自动打破这种等待链的机制。
可靠的解决方案：切断同步等待链
要避免这一问题，核心思路是让父任务避免阻塞等待，转而采用异步方式响应子任务的完成。以下是几种行之有效的方案：
- 使用 CompletableFuture 进行链式编排：将子任务作为一个异步阶段提交，父任务的后续逻辑通过
thenApply、thenAccept等方法进行回调处理。这种方式完全避免了显式的get()调用，从设计上切断了阻塞链。 - 换用 ForkJoinPool：即使将
ForkJoinPool的并行度设置为1，其内部的工作窃取机制也允许子任务由执行父任务的同一线程进行“内联执行”（inline execution），而不会进入队列等待，从而有效规避死锁。 - 分离线程池：让父任务和子任务使用不同的线程池执行。例如，父任务使用单线程池，子任务则提交给另一个独立的线程池（即使只有2个线程）。这种物理隔离彻底消除了资源竞争。
- 谨慎使用 CallerRunsPolicy：为线程池配置
CallerRunsPolicy拒绝策略。当任务队列满时，新提交的任务会在调用者线程（即提交任务的父任务线程）上直接运行。这虽然能解燃眉之急，但破坏了异步执行的语义，仅适用于简单的特定场景。
