3. Spring Boot 并发现状：ThreadPoolTaskExecutor、@Async、CompletableFuture 的局限性与痛点分析

Spring Boot 应用在应对高并发 IO 密集型任务（如批量数据聚合、外部服务编排、实时流处理）时，通常依赖 ThreadPoolTaskExecutor、@Async 注解以及 CompletableFuture 这三板斧。然而，当业务场景从“简单异步”升级为“Go 风格的高吞吐并发聚合”时，这三者的设计缺陷与性能瓶颈便会集中爆发。

3.1 ThreadPoolTaskExecutor：线程池的“硬边界”

ThreadPoolTaskExecutor 是 Spring 对 java.util.concurrent.ThreadPoolExecutor 的封装，提供了核心线程数、最大线程数、队列容量等参数。但在高并发聚合建模中，它存在以下硬伤：

3.2 @Async 注解：声明式异步的“黑盒陷阱”

@Async 通过 AOP 代理将方法调用提交到线程池，看似简洁，但在聚合建模中暴露出以下问题：

• 无返回值传播：默认使用 void 或 Future<V>，无法像 CompletableFuture 那样链式组合多个异步结果。
• 异常处理隐式丢失：被 @Async 修饰的方法内抛出的异常，若未在调用方捕获，会被线程池的 afterExecute 吞掉，导致聚合任务静默失败。
• 线程池绑定静态：@Async 默认使用 SimpleAsyncTaskExecutor（每次新建线程），或通过 @Bean 指定单一线程池，无法按聚合任务类型动态路由。
• 上下文传递困难：MDC、SecurityContext、事务上下文无法自动传递到异步线程，需手动包装 TaskDecorator，增加样板代码。

// @Async 典型痛点：异常丢失与上下文断裂
@Async
public CompletableFuture<Result> fetchData(String id) {
    // 若此处抛出 RuntimeException，调用方 get() 时才会收到 ExecutionException
    // 但若返回 void，异常完全丢失
    if (id == null) throw new IllegalArgumentException("ID must not be null");
    return CompletableFuture.completedFuture(new Result(id));
}

3.3 CompletableFuture：链式编排的“回调地狱”与资源泄漏

CompletableFuture 提供了 thenApplyAsync、allOf、anyOf 等组合算子，看似解决了 @Async 的链式问题，但在高扇出聚合场景下，其内部实现存在严重性能隐患：

3.4 痛点全景图：Spring 并发模型 vs Go 并发模型

下图直观对比了 Spring 传统并发栈与 Go goroutine + channel 模型在聚合建模中的关键差异：

3.5 聚合建模中的典型失败场景

以一个“批量查询用户订单并聚合统计”的典型聚合任务为例，展示上述痛点的连锁反应：

1. 任务提交：1000 个用户 ID 通过 CompletableFuture.allOf() 并发提交到 ThreadPoolTaskExecutor（核心 10，最大 50）。
2. 队列积压：由于每个子任务需调用外部订单服务（平均延迟 200ms），50 个线程全部阻塞在 IO 等待上，剩余 950 个任务堆积在队列中。
3. GC 风暴：每个子任务创建 3 个 Future 对象（supplyAsync + thenApply + exceptionally），瞬间产生 3000 个对象，触发 Young GC。
4. 超时雪崩：队列中任务等待时间超过 5s，触发 Hystrix 熔断，大量请求直接返回 fallback，聚合结果不完整。
5. 线程泄漏：部分子任务因网络抖动抛出异常，@Async 未捕获，线程池中线程状态异常，无法复用。

3.6 小结：何时该放弃 Spring 原生并发方案？