thenApply 不保证在调用线程执行，而是由完成前一阶段的线程（如 ForkJoinPool 工作线程）直接触发后续操作，这是其异步非阻塞设计的核心机制。
“thenapply 不保证在调用线程执行，而是由完成前一阶段的线程（如 forkjoinpool 工作线程）直接触发后续操作，这是其异步非阻塞设计的核心机制。”
CompletableFuture.thenApply 常被误认为是“同步”方法（因无 Async 后缀），但其实际语义是非阻塞式依赖执行，而非“在当前线程同步调用”。Java 官方文档明确指出：
Actions supplied for dependent completions of non-async methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
这意味着：thenApply 的函数体（即 lambda）不绑定调用线程，而由触发该阶段完成的线程执行——通常是上游任务完成时所在的线程。在你的示例中：
CompletableFuture<integer> cf = CompletableFuture.supplyAsync(() -> {
System.out.println("log-sA: " + Thread.currentThread().getName()); // ForkJoinPool.worker-3
return 40;
}).thenApply(a -> {
System.out.println("log-tA: " + Thread.currentThread().getName()); // 同一线程！→ ForkJoinPool.worker-3
return a + 40;
});</integer>
supplyAsync 在 ForkJoinPool.commonPool() 中异步执行并完成；一旦完成，thenApply 的回调立即由该 worker 线程接力执行（避免线程切换开销），因此输出中 log-tA 仍显示 ForkJoinPool.commonPool-worker-3。
⚠️ 注意：这不是 bug，而是性能优化设计。thenApply 的“非异步”仅表示不显式提交新任务到线程池，但执行上下文完全取决于 Completion 事件的发布者。
若你严格要求在主线程执行 thenApply 逻辑（例如更新 UI 或依赖主线程上下文），必须显式调度：
.thenApplyAsync(fn, Runnable::run) // ❌ 错误：Runnable::run 不是 Executor
.thenApplyAsync(fn, Executors.newSingleThreadExecutor()) // ✅ 自定义线程池（注意资源释放）
// 更安全的做法（避免阻塞主线程）：
.thenAcceptAsync(result -> {
// 主线程安全操作（如 SwingUtilities.invokeLater / Platform.runLater）
}, Platform::runLater); // JavaFX 示例
✅ 总结：
- thenApply = 由完成线程直接执行（零调度延迟，推荐用于纯计算）；
- thenApplyAsync() = 强制提交到指定/默认线程池（可跨线程，适合 I/O 或需隔离上下文场景）；
- 所谓“同步”仅指调用链构建的同步性（返回新 CF 实例），绝非执行线程的同步性。理解这一点，是正确驾驭 CompletableFuture 异步流的关键。
