spring项目中业务逻辑涉及异步调用
两种异步模型的分叉点
@Async 和CompletableFuture.supplyAsync(() -> { … }) 正面对比
一、两种写法放一起看 👇
1️⃣ 你现在用的（Spring 推荐，企业级）
@Async
public void runTaskAsync(String pasaTaskId, String daHost, String runPath) {
// 异步逻辑
}
调用：
pasaAsyncService.runTaskAsync(…);
2️⃣ CompletableFuture 写法
CompletableFuture.supplyAsync(() -> {
// 异步逻辑
return result;
});
或：
CompletableFuture.runAsync(() -> {
// 无返回值
});
二、核心区别对比（重点）
对比点 @Async CompletableFuture.supplyAsync
线程池管理 ✅ Spring 统一管理 ❌ 默认 ForkJoinPool
是否推荐在 Spring 项目用 ✅ 强烈推荐 ⚠️ 有条件使用
AOP / 事务 / 安全上下文 ✅ 支持 ❌ 不支持
可读性 ✅ 清晰 ⚠️ 容易变复杂
任务编排 ❌ 一般 ✅ 非常强
异常处理 try-catch exceptionally / handle
适合场景 后台任务、接口触发 并行计算 / 流式处理
三、最关键的一点（90% 的坑）
❌ CompletableFuture 默认线程池是：
ForkJoinPool.commonPool()
问题：
❌ 和 JVM 里所有 CompletableFuture 共用
❌ 容易被 CPU 密集任务拖死
❌ 和 Spring 事务、日志 MDC、SecurityContext 无关
👉 在 Web 后台 / 微服务 中，不推荐直接用默认写法
四、如果你非要用 CompletableFuture，正确姿势是这样
✔ 指定线程池（否则不如不用）
CompletableFuture.runAsync(
() -> {
// 业务逻辑
},
pasaExecutor // Spring 注入的线程池
);
这样 本质上和 @Async 是一回事
五、结合你现在这个业务：该选哪个？
你的场景回顾
点击按钮 → 调 DA 接口
不关心返回值
不阻塞接口
需要日志、状态、可控线程
✅ 最优解（你现在的）
@Async
public void runTaskAsync(…) { … }
这是标准后台任务写法，没有任何问题
六、什么时候 CompletableFuture 更适合？
适合 CompletableFuture 的典型场景
CompletableFuture f1 = …
CompletableFuturef2 = …
CompletableFuture result =
f1.thenCombine(f2, (a, b) -> …)
.thenApply(…)
.exceptionally(…)
✔ 并行查询
✔ 聚合结果
✔ 链式处理
✔ 有返回值
👉 偏“计算 / 编排”
七、一句话结论
🔥 Spring 项目中：
接口触发、后台执行 → @Async
并行计算、结果编排 → CompletableFuture + 自定义线程池
❌ 永远不要在 Web 项目里裸用 CompletableFuture.supplyAsync()