submit()嵌套调用同一线程池会卡住，因所有线程忙于执行任务且排队的新任务无人处理，形成“自己等自己”的死锁链；典型于CompletableFuture.thenApply或@Async内再调用@Async。
为什么 submit() 嵌套调用同一线程池会卡住
线程池里每个线程在执行任务时，如果又调用 submit() 把新任务塞回同一个池子，而此时所有线程都在忙（包括自己），新任务就只能排队等空闲线程——但没人能腾出手来取它。这就形成「自己等自己」的等待链。
典型场景：一个 CompletableFuture 的 thenApply() 里又向同一线程池提交任务；或 Spring 的 @Async 方法内部再调用另一个 @Async 方法，默认共用同一个 ThreadPoolTaskExecutor。
- 不是所有线程池都这样，
newFixedThreadPool(1)最容易复现，newCachedThreadPool()表面不卡但可能耗尽内存 -
ForkJoinPool.commonPool()同样危险，尤其在parallelStream()+supplyAsync()嵌套时 - 错误现象通常是「某批任务永远不结束」，线程 dump 里能看到一堆
WAITING状态，堆栈停在BlockingQueue.take()或ForkJoinPool.awaitWork()
怎么判断当前线程是否属于目标线程池
没法直接问「我在不在池子里」，但可以间接探查：线程名通常带池子标识（如 pool-1-thread-1），且 Thread.currentThread().getThreadGroup() 一般和池子创建时的组一致。更可靠的是记录池子初始化时的 ThreadGroup 或自定义线程工厂打标记。
- 不要依赖
Thread.getName().contains("pool")—— 名字可被覆盖，也不够精确 - 推荐做法：构建线程池时用
ThreadFactoryBuilder（Guava）或自定义ThreadFactory，给线程加唯一前缀，比如"io-pool-" + i - 运行时检查：
if (Thread.currentThread().getName().startsWith("io-pool-")) { /* 避免再 submit */ }
嵌套任务必须用同一线程池？替代方案有哪些
绝大多数情况下，不需要。强行复用反而制造瓶颈。关键是区分任务类型：CPU 密集型、IO 密集型、响应式回调，它们对线程资源的需求完全不同。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- CPU 密集任务：用
ForkJoinPool或固定大小的newWorkStealingPool()，别让它干 IO - IO 密集任务（DB、HTTP）：单独配一个带足够队列容量的
newFixedThreadPool(n)，n 通常设为 2–4 × CPU 核心数 - 回调类轻量任务（如日志、指标上报）：用单线程池
Executors.newSingleThreadExecutor()，避免干扰主流程 - Spring 用户：在
@Async注解里指定value = "ioTaskExecutor"，别依赖默认 bean
不小心写出了嵌套 submit，怎么快速定位和修复
最有效的办法是加一层「提交守门人」——把原始线程池包装成代理，拦截 submit() 调用，检查当前线程是否已在池中执行。一旦发现嵌套，立刻抛异常或降级到同步执行。
public class SafeThreadPoolExecutor extends ThreadPoolExecutor {
private final String poolName;
<pre class='brush:java;toolbar:false;'>public SafeThreadPoolExecutor(int core, int max, long keep, TimeUnit unit,
BlockingQueue<Runnable> q, String name) {
super(core, max, keep, unit, q, new NamedThreadFactory(name));
this.poolName = name;
}
@Override
public <T> Future<T> submit(Callable<T> task) {
if (Thread.currentThread().getName().startsWith(poolName)) {
throw new IllegalStateException("Nested submit to " + poolName + " detected");
}
return super.submit(task);
}}
- 这个检查只在开发/测试环境开启，生产可关掉，但建议保留日志告警
- 比加监控更早发现问题：编译期无法发现，但运行几秒内就能触发异常
- 注意：不能只检查
Thread.currentThread() == poolThread，因为线程会被复用，名字才是稳定标识
真正难的不是写对一次，而是团队里所有人写的异步逻辑都遵守同一套线程边界规则——没有统一命名、没有文档约束、没有 CI 检查时，嵌套提交会像毛细血管一样悄悄长出来。
