4. 异步任务编排基础：什么是任务编排、CompletableFuture原理、回调机制与线程模型
在SSO单点登录场景中，一次登录请求往往需要同时或依次完成令牌校验、用户信息拉取、会话缓存写入、权限数据同步等多个子任务。如果采用串行执行，响应延迟会随任务数量线性增长；如果采用无协调的并行执行，又可能因依赖关系混乱导致数据不一致。异步任务编排正是解决这一矛盾的核心技术。
4.1 什么是任务编排
任务编排（Task Orchestration）是指将一组独立或存在依赖关系的异步任务，按照指定的执行顺序、并行策略、异常处理和结果合并规则组织起来，形成一个可预测、可监控的执行流程。它不同于简单的多线程并发，而是强调任务之间的依赖关系和数据流。
| 对比维度 | 原始多线程 | 任务编排 |
|---|---|---|
| 任务关系 | 无显式依赖，靠锁/信号量协调 | 声明式依赖（thenApply, thenCompose） |
| 异常处理 | try-catch 分散在各线程 | 集中式 exceptionally / handle |
| 结果合并 | 手动 Future.get() 阻塞等待 | allOf / anyOf 非阻塞组合 |
| 线程管理 | 直接操作 Thread / Executor | 通过 CompletableFuture 隐式调度 |
| 可读性 | 回调嵌套（Callback Hell） | 链式调用，接近同步代码风格 |
SSO 场景示例：用户登录成功后，编排任务 A（校验令牌）、任务 B（查询用户角色）、任务 C（写入分布式会话缓存）。A 与 B 可并行，C 必须等待 A 和 B 都完成。使用编排后，代码结构清晰且延迟最优。
4.2 CompletableFuture 原理
CompletableFuture 是 Java 8 引入的异步编程工具，它实现了 Future 和 CompletionStage 两个接口。其核心原理可以概括为：一个可手动完成、可链式回调、可组合的异步结果容器。
4.2.1 核心状态机
每个 CompletableFuture 内部维护一个 volatile 修饰的 result 字段，状态转换遵循以下规则：
- 初始状态：result == null，表示任务尚未完成。
- 正常完成：通过 complete(T value) 或异步执行成功，result 指向一个 AltResult 或直接存储结果值。
- 异常完成：通过 completeExceptionally(Throwable) 或异步执行抛出异常，result 指向一个封装了异常的 AltResult。
- 不可逆：一旦 result 被赋值，后续的 complete 调用将被忽略。
// 核心状态转换示意（简化伪代码）
public class CompletableFuture<T> {
volatile Object result; // null: 未完成, 其他: 已完成
public boolean complete(T value) {
return UNSAFE.compareAndSwapObject(this, resultOffset, null, value);
}
public T get() throws InterruptedException, ExecutionException {
// 自旋或阻塞等待 result 非 null
while (result == null) { /* 等待 */ }
return reportGet(result);
}
}
4.2.2 任务编排的依赖注册机制
当调用 thenApply(fn) 时，CompletableFuture 并不会立即执行 fn，而是创建一个新的 CompletableFuture（称为依赖节点），并将 fn 注册到当前节点的依赖栈（stack）中。当前节点完成时，会弹出栈中的依赖动作并触发执行。
关键设计：依赖注册采用 Treiber Stack（无锁并发栈），通过 CAS 操作将回调函数压入栈顶，避免了锁竞争。这是 CompletableFuture 在高并发下仍保持高性能的重要原因。
4.3 回调机制
回调机制是任务编排的“粘合剂”。CompletableFuture 提供了三类回调风格，分别对应不同的编排需求：
| 回调类型 | 方法示例 | 输入 | 输出 | 典型用途 |
|---|---|---|---|---|
| 转换型 | thenApply | 上一个阶段的结果 | 新结果 | 数据格式转换、字段提取 |
| 消费型 | thenAccept | 上一个阶段的结果 | 无（Void） | 日志记录、缓存写入 |
| 执行型 | thenRun | 无 | 无（Void） | 触发后续动作，不关心数据 |
| 组合型 | thenCompose | 上一个阶段的结果 | 新的 CompletableFuture | 异步依赖调用（flatMap） |
| 合并型 | thenCombine | 两个阶段的结果 | 合并后的结果 | 并行查询后聚合数据 |
// SSO 场景中的回调链示例
CompletableFuture.supplyAsync(() -> validateToken(request.getToken()))
.thenApply(tokenInfo -> fetchUserProfile(tokenInfo.getUserId()))
.thenAccept(profile -> cacheService.set("session:" + profile.getUserId(), profile))
.exceptionally(ex -> {
log.error("SSO 会话构建失败", ex);
return null;
});
4.4 线程模型
CompletableFuture 的线程模型决定了编排任务的执行位置和并发行为。理解线程模型对于避免死锁、线程饥饿和上下文切换开销至关重要。
4.4.1 默认线程池
- ForkJoinPool.commonPool()：所有未指定 Executor 的异步方法默认使用此池。它是 JVM 全局共享的并行池，线程数 = CPU 核心数 - 1（至少 1）。
- 问题：在 IO 密集型任务（如 SSO 中的远程 RPC 调用、数据库查询）中，commonPool 的线程数过少，容易导致所有线程阻塞在 IO 上，CPU 利用率极低。
SSO 生产环境警告：永远不要在 IO 密集型异步任务中使用默认的 commonPool。必须自定义线程池，例如
new ThreadPoolExecutor(核心数*2, 最大数, ...)，并显式传递给 supplyAsync(task, executor)。
4.4.2 回调执行的线程规则
回调方法（thenApply、thenAccept 等）的执行线程遵循以下规则：
- 如果当前 CompletableFuture 已完成：回调由调用线程（发起 thenApply 的线程）直接执行。
- 如果当前 CompletableFuture 未完成：回调被注册到依赖栈，由完成当前任务的线程（通常是 ForkJoinPool 中的工作线程）执行。
- 如果指定了 Executor：无论当前任务是否完成，回调都在指定的 Executor 中执行。
// 显式指定线程池的最佳实践
ExecutorService ssoExecutor = new ThreadPoolExecutor(
8, 16, 60L, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(1024),
new ThreadFactoryBuilder().setNameFormat("sso-async-%d").build()
);
CompletableFuture.supplyAsync(() -> rpcService.checkToken(token), ssoExecutor)
.thenApplyAsync(profile -> cacheService.setSession(profile), ssoExecutor)
.thenAcceptAsync(result -> auditLog.record("login", result), ssoExecutor);
4.4.3 线程模型对比
| 方法后缀 | 执行线程 | 适用场景 |
|---|---|---|
| 无后缀（如 thenApply） | 由完成线程或调用线程决定 | 轻量计算，避免线程切换 |
| Async（如 thenApplyAsync） | 默认 ForkJoinPool 或指定 Executor | 耗时操作，需要隔离线程池 |
| Async + Executor | 指定的线程池 | 生产环境首选，完全控制并发 |
4.5 本章小结
- 任务编排是 SSO 异步架构的骨架，通过声明式依赖替代手动同步，提升代码可读性和执行效率。
- CompletableFuture 基于无锁栈（Treiber Stack）实现依赖注册，状态机保证结果不可变，是 Java 生态中最成熟的任务编排工具。
- 回调机制提供转换、消费、组合、合并等多种语义，覆盖 SSO 场景中 90% 以上的异步协作需求。
- 线程模型必须根据任务类型（CPU 密集型 vs IO 密集型）选择线程池，SSO 生产环境强制使用自定义线程池并显式传递。