不能在Tomcat全局线程池的核心线程上调用join()，因其会破坏“先扩线程、后排队”的反向逻辑，导致核心线程阻塞、新请求无法处理，引发雪崩；应改用CompletableFuture或虚拟线程解耦。
不能在 Tomcat 全局线程池的核心线程上调用 join()，根本原因不是语法错误，而是它会直接破坏 Tomcat 线程池“先扩线程、后排队”的反向执行逻辑，并引发线程阻塞雪崩——核心线程被自己卡死，新请求既无法新建线程，也无法入队，整个连接处理链路瞬间僵住。
Tomcat 线程池本就不该被“等”
Tomcat 的线程池（org.apache.tomcat.util.threads.ThreadPoolExecutor）是 JDK 原生 ThreadPoolExecutor 的魔改版：它把“先入队”逻辑彻底翻转为“先扩容”。也就是说：
- 有请求进来，只要当前线程数 <
maxThreads，就立即创建新线程处理（哪怕还没到minSpareThreads） - 只有线程数已达
maxThreads，才把请求塞进acceptCount队列（本质是 Acceptor 接收队列，非任务队列） - 队列也满了？直接拒绝（Connection reset / 503）
这个设计是为了快速响应突发流量，避免任务在队列里堆积延迟。但一旦你在某个正在运行的 Tomcat 工作线程（比如一个 Servlet 处理线程）里调用 otherThread.join()，就等于让这个宝贵的、本该立刻返回给连接器复用的线程，原地挂起等待另一个线程结束——它不再接受新任务，也不释放自身资源，相当于从“活跃工作线程”退化成“静默占位线程”。
join() 会绕过所有线程池治理机制
join() 是 JVM 层面的线程同步原语，完全不经过 ThreadPoolExecutor 的任何管控逻辑：
- 它不会触发线程池的拒绝策略（
RejectedExecutionHandler） - 不会触发核心/非核心线程的存活时间判断（
keepAliveTime） - 不会通知线程工厂做命名或上下文清理
- 更不会触发 Tomcat 自己的线程空闲回收（如
minSpareThreads补充）
结果就是：你用一个核心线程去 join() 另一个可能卡在 DB 查询、远程调用或锁竞争里的线程，这个 Tomcat 工作线程就永久“失联”了。而 Tomcat 并不知道它已失效，仍把它计入活跃线程数，后续请求只能继续争抢剩余线程——当并发稍高，很快就会耗尽全部 maxThreads，新连接连 accept 都进不来。
真实故障场景：一个 join 拖垮整台实例
典型案例如下：
- 用户请求进入 Tomcat，分配到线程 A（当前已用 199/200）
- A 执行业务逻辑，启动子线程 B 做异步日志落盘，并调用
B.join()等它写完 - B 因磁盘 IO 延迟或日志框架锁竞争卡住 3 秒以上
- A 就在这 3 秒内持续阻塞，无法处理后续请求，也不能归还给线程池
- 此时第 200 个请求进来，发现无空闲线程、
maxThreads已满，且acceptCount也满，直接被 Tomcat 拒绝（RST 或超时） - 如果这类逻辑在登录、下单等高频入口出现，几秒内就能让整台应用实例不可用
替代方案：用非阻塞 + 回调或虚拟线程解耦
真正要等结果，必须脱离 Tomcat 工作线程上下文：
-
推荐：用
CompletableFuture+ 自定义业务线程池，把耗时操作提交到隔离线程池，主线程立即返回，通过thenApply或whenComplete处理结果 -
升级路径：JDK 21+ 用虚拟线程，
Thread.ofVirtual().start(() -> {...}).join()开销极小，且不会挤占 Tomcat 平台线程，但注意虚拟线程不能直接用于 Servlet 容器回调（需 Spring Boot 3.2+ 或手动适配） -
兜底方案：加超时 + fallback，绝不写无参
join()；必须等，就用join(500)并配合异常分支释放资源
一句话总结：Tomcat 的线程是“连接处理器”，不是“业务执行器”。让它等，等于让快递员蹲在客户门口等包裹打包完成——包裹没来，其他客户全得干等。
