线程池“饥饿”死锁本质是任务调度失衡导致新任务无限等待，主因是父子任务共用同一固定大小线程池并同步等待子任务，形成线程自依赖；需隔离执行层级、避免同池内阻塞等待、使用独立线程池或异步回调。
线程池“饥饿”死锁，本质不是传统意义上的死锁（如循环等待锁），而是因任务调度失衡导致线程长期被占用、新任务无法获取线程而无限等待——尤其在父子任务共用同一固定大小线程池时极易发生。
为什么父子任务共用线程池会触发饥饿？
当一个任务（父任务）提交子任务到**同一个线程池**，且父任务需等待子任务结果（例如调用 future.get() 或 join()），就可能形成“线程自依赖”：父任务占着一个线程阻塞等待，而子任务又因线程池已满无法被调度执行。若所有线程都处于类似状态，整个池就陷入停滞。
典型场景包括：
- 使用
Executors.newFixedThreadPool(2)，父任务 fork 出 2 个子任务并同步等待 - CompletableFuture 链式调用中混用
thenApply（默认 ForkJoinPool.commonPool()）和thenApplyAsync(fn, pool)但误传了同一受限池 - 自定义业务逻辑中，服务 A 调用服务 B，而两者底层共用一个线程池处理回调或异步子流程
变量资源耗尽：不只是线程数不够
“饥饿”常伴随其他资源枯竭，加剧不可用：
- 内存堆积：大量等待中的 Future 对象、未完成的 CompletableFuture 实例持续持有引用，GC 无法回收
- 连接/句柄泄漏：子任务本该释放的数据库连接、HTTP 客户端连接，在阻塞等待中迟迟不归还连接池
- ThreadLocal 泄漏：线程复用下，父任务设置的 ThreadLocal 变量未清理，被后续子任务误读或累积内存占用
如何避免父子任务引发的线程池饥饿？
核心原则是：**隔离执行层级，禁止同步等待同池中的子任务**。具体可操作：
- 为父子任务划分不同线程池：父任务用业务池，子任务交由专用计算池（如
ForkJoinPool.commonPool()或独立newCachedThreadPool()） - 避免在池内线程中调用
get()/join()等阻塞方法；改用异步链式回调（如thenCompose、whenComplete） - 若必须同步等待，确保线程池有“冗余容量”：最小线程数 ≥ 最大嵌套深度 × 单次并发子任务数（不推荐，仅临时缓解）
- 监控关键指标：线程池活跃线程数、队列积压任务数、平均任务等待时间；突增即预警潜在饥饿
一个典型修复示例
错误写法：
ExecutorService pool = Executors.newFixedThreadPool(3);
Future<string> f1 = pool.submit(() -> {
Future<integer> f2 = pool.submit(() -> computeHeavy()); // 子任务提交到同池
return "result-" + f2.get(); // 父任务阻塞等待 → 风险！
});</integer></string>修复后：
ExecutorService bizPool = Executors.newFixedThreadPool(3);
ExecutorService computePool = Executors.newFixedThreadPool(4); // 独立池
Future<string> f1 = bizPool.submit(() -> {
Future<integer> f2 = computePool.submit(() -> computeHeavy());
return "result-" + f2.get(); // 等待发生在 bizPool 线程，不影响 computePool 调度
});</integer></string>
