单线程执行器中父子任务相互等待导致的死锁分析与防范

在异步编程实践中，存在一种极为隐蔽的死锁风险，它并非源于传统的锁资源竞争，而是由任务调度层面的设计缺陷所引发。具体而言，当开发者在一个单线程 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 拒绝策略。当任务队列满时，新提交的任务会在调用者线程（即提交任务的父任务线程）上直接运行。这虽然能解燃眉之急，但破坏了异步执行的语义，仅适用于简单的特定场景。