completablefuture 的核心是避免阻塞主线程，应使用 thenaccept、thenapply、handle 等非阻塞回调处理结果，禁用 get()/join()；io 任务需指定专用线程池以防拖垮 commonpool；多任务协同通过 allof、thencombine 等组合器实现回调式编排。
CompletableFuture 本身的设计目标就是不阻塞主线程，关键在于**不用 get() 或 join() 主动等待**，而是用回调或组合方式处理结果。
用 thenAccept / thenApply 等非阻塞回调处理结果
主线程提交异步任务后立即继续执行，后续逻辑交给回调线程（默认 ForkJoinPool.commonPool，也可指定）：
-
thenAccept：消费结果，无返回值，适合日志、更新 UI、发通知等 -
thenApply：转换结果并返回新 CompletableFuture，适合链式加工（如 JSON 解析 → 映射为对象） -
handle：统一处理成功和异常，比thenAccept + exceptionally更简洁
示例：
CompletableFuture.supplyAsync(() -> userService.loadUsers())
.thenApply(users -> users.stream().filter(u -> u.isActive()).toList())
.thenAccept(activeUsers -> System.out.println("活跃用户：" + activeUsers.size()))
.exceptionally(e -> { log.error("加载失败", e); return null; });
整个过程主线程从不暂停，所有后续操作都在异步线程中触发。
避免使用 get() 和 join()（除非必要）
这两个方法会强制当前线程阻塞，直到结果就绪，直接抵消异步优势：
- 在 Web 请求线程（如 Spring MVC 的 controller）中调用
future.get()，等于把异步变同步，吞掉并发能力 - 若必须同步获取（如单元测试、脚本启动逻辑），可设超时：
future.get(3, TimeUnit.SECONDS)，防止无限等待 - 生产环境尽量用回调驱动流程，而不是“等结果回来再干下一件事”
指定专用线程池，防止 IO 阻塞拖垮 commonPool
默认的 ForkJoinPool.commonPool() 适合 CPU 密集型任务；但数据库查询、HTTP 调用等 IO 操作容易长时间阻塞线程，导致 commonPool 线程耗尽，连带影响其他异步任务甚至主线程调度：
- 创建独立的 IO 线程池：
Executors.newFixedThreadPool(20)或更优的new ThreadPoolExecutor(10, 50, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(100)) - 显式传入 supplyAsync：
supplyAsync(() -> http.get("/api/data"), ioPool) - 这样即使某个请求卡住 5 秒，也不会占用 commonPool，主线程和其他异步任务照常运行
多个异步任务协同，仍不阻塞主线程
用 allOf、anyOf、thenCombine 等组合器协调多个 CompletableFuture，全部基于回调机制：
CompletableFuture.allOf(f1, f2, f3).thenRun(() -> System.out.println("全部完成"))-
f1.thenCombine(f2, (r1, r2) -> r1 + r2)：等两个都完成，再合并处理 - 这些方法返回的仍是 CompletableFuture，无需
get，可继续链式编排
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
