企业官网建设流程全解析

做并发开发这几年，我踩过最大的坑，就是把异步任务一股脑塞进 Future 里，然后用 get() 把主线程活活堵死。后来项目里要同时调订单、库存、风控三个远程服务，串行跑一次要800毫秒，用上 CompletableFuture 并行编排后直接压到300毫秒。另一类场景更隐蔽——多线程分阶段协作，比如批处理里“读取、校验、上报”必须按批次推进，人肉用 CountDownLatch 或者 CyclicBarrier 写循环，代码丑到不敢给同事看，后来换成 Phaser 才真正体会到什么叫阶段协调。这篇博文我就想把这两块经验完整铺开，结合 Spring Boot 落地到真实业务里，适合正在啃 JUC、准备面试、或者已经在生产环境里被异步编排折腾过一遍的读者。

先说清楚：这俩工具不是学完就完事的 API 背诵，它们背后有一套完整的“并发串行化”思路。CompletableFuture 解决的是“多个异步任务怎么编排、结果怎么聚合、异常怎么传递”的问题；Phaser 解决的是“多阶段任务怎么让一批线程步调一致”的问题。下面我会从原理拆到实战，再给一堆我实际踩过、排查过的问题，尽量让你看完能直接抄。

1. CompletableFuture 到底解决了什么问题

1.1 从 Future 到 CompletableFuture：异步结果的可用性差异

Java 8 之前我们用的 Future 其实是个很原始的异步结果容器。你向线程池提交一个任务，拿回来一个 Future，真正要结果的时候调用 future.get()，它会阻塞当前线程直到任务完成。问题就在于“阻塞”这两个字，一旦你有多个异步任务想并行执行，很多人的第一版代码会写成这样：

Future<String> userFuture = executor.submit(() -> queryUser()); Future<String> orderFuture = executor.submit(() -> queryOrder()); String user = userFuture.get(); // 第一个阻塞 String order = orderFuture.get(); // 第二个阻塞

这代码表面上是并行了，但两次 get 都是串行阻塞，如果能快速等来第一个结果倒还好，真正要命的是任务之间如果有依赖，比如下一个任务需要上一个任务的结果，Future 本身完全做不到“完成即触发”，只能靠你在 get 之后手动把结果传给下一次提交。这种写法一旦落到复杂业务里，就是一堆回调地狱，代码可读性直接崩塌。

CompletableFuture 的核心思想是把“异步任务”抽象成一个可以被组合、被监听、被回调的 CompletableFuture 对象，它内部维护了一套完成状态机。任务完成时会自动触发注册好的回调，你可以通过 thenApply、thenCompose、allOf 这些方法把任务串起来，也可以给每个任务挂上 exceptionallly 处理异常。所以它能优雅地实现“一个任务完成后自动执行下一个”，并且天然支持并行任务的结果聚合。

1.2 为什么不建议用 get() 阻塞等结果

有些开发会问，我业务里反正要等结果，直接用 join() 或者 get() 拿一下不就行了吗？单任务确实没毛病，但一旦上到多任务编排，你用 get() 把整个主流程阻塞住，那你开异步的意义就被削弱了一大半——你仍然把线程池里那条“执行线程”和主线程串成了一个同步模型，吞吐量提不上去，遇到网络抖动还会出现线程池线程被大量占住的连锁反应。

更隐蔽的问题是异常处理。Future.get() 拿到异常时抛的是 ExecutionException，你要再 getCause() 才能看到真正的异常，而 CompletableFuture 的做法是让异常流随着回调链一直往下传，你可以在链条的任意位置用 exceptionally/handle 兜住。我曾见过同事的代码用 try-catch 包了三次 Future.get()，最后还漏掉了 CompletionException 的包装，排查一个 NPE 花了一下午。这个痛点其实在面试里也经常被问到，标准答案就是“阻塞式等待 + 异常包装不可控，所以要选择事件驱动的 CompletableFuture”。

2. CompletableFuture 核心 API 实战拆解

2.1 开启异步任务：runAsync 与 supplyAsync 的选择

异步任务分两种：有返回值和无返回值。有返回值用 supplyAsync，没有返回值用 runAsync。这里有一个很多人忽略的点：这两个方法默认用的是 ForkJoinPool.commonPool()，这是一个 JVM 全局共享的线程池，池大小默认是 CPU 核心数减一。如果你把所有业务异步任务都丢给它，一旦任务里有 IO 等待（HTTP 调用、数据库查询），整个 JVM 的公共池会被饿死，其他依赖 commonPool 的并行流计算也会被拖累。

所以我在 Spring Boot 项目里从来不用默认池，而是自定义一个 ThreadPoolTaskExecutor 注入进来。下面是我常用的线程池配置模板，直接在配置类里声明一个 Bean：

@Bean(name = "asyncExecutor") public ThreadPoolTaskExecutor asyncExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(200); executor.setKeepAliveSeconds(60); executor.setThreadNamePrefix("biz-async-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }

关于线程池参数，网上标准答案是 CPU 密集型用 N+1，IO 密集型用 2N，但真实业务基本是混合型的，我建议先按核心大小 = 实际服务依赖的下游实例数 × 每个请求并行调用数来估，别贪多，线程多到一定程度上下文切换开销反而让吞吐量下降。队列容量这里我用了 200，配合 CallerRunsPolicy 拒绝策略，意思是线程池满了之后新任务直接由提交线程执行，保证任务不丢，同时天然对上游产生背压。

2.2 回调编排：thenApply、thenAccept、thenCompose 的适用边界

CompletableFuture 的回调方法看起来多，其实按“返回值”和“是否异步”两个维度就能记清楚。thenApply 接收上一个任务结果，返回一个新的结果，适合做串行转换；thenAccept 接收结果但不再返回，适合做消费动作；thenRun 连结果都不接收，只负责“跑完下一个动作”。更关键的是，这三个方法有没有带 Async 后缀，区别在于执行回调的线程：不带的，在同一个线程里同步完成（除非上一步还没结束）；带 Async 的，会重新丢进线程池执行一次。

我自己最喜欢用 thenCompose，因为它是扁平的。举个例子，先查用户，再根据用户的角色查权限配置，两个任务有依赖关系，如果写成 thenApply，因为嵌套 CompletableFuture，你后面还得手动 join 或 flatten，而 thenCompose 直接帮你拍平成一维的流：

CompletableFuture.supplyAsync(this::queryUser, asyncExecutor) .thenCompose(user -> CompletableFuture.supplyAsync(() -> queryPermissionByRole(user.getRole()), asyncExecutor)) .thenAccept(permission -> log.info("权限查询完成: {}", permission));

这个小链子串下来，逻辑非常顺。但如果你在业务里发现回调链特别深，已经超过四五层，建议马上停下来重构——要么把链子拆成多个变量保存中间结果，要么提取方法。链式调用好读是有上限的，超过一定深度之后排错全靠看堆栈，那体验并不比回调地狱好多少。

2.3 多任务组合：allOf 与 anyOf 的正确打开方式

多任务并行聚合最常用的就是 allOf：等所有任务都完成。它本身返回一个 CompletableFuture ，并不会自动帮你聚合各个任务的结果，你要自己维护一个任务数组，全部完成后遍历数组拿值。这里我通常会封装一个工具方法，把结果收集成一个 Map 或者 List，避免业务代码里到处写 getNow 和 join：

CompletableFuture<String> userFuture = CompletableFuture.supplyAsync(userService::getUser, asyncExecutor); CompletableFuture<String> orderFuture = CompletableFuture.supplyAsync(orderService::getOrder, asyncExecutor); CompletableFuture<String> couponFuture = CompletableFuture.supplyAsync(couponService::getCoupon, asyncExecutor); List<CompletableFuture<String>> futures = List.of(userFuture, orderFuture, couponFuture); CompletableFuture<Void> all = CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])); all.join(); futures.forEach(f -> System.out.println(f.getNow("default")));

anyOf 用在“多个数据源谁先返回用谁”的场景，比如同时查本地缓存和远程服务，谁先回来就结束。但这里有一个坑：anyOf 返回的是 CompletableFuture

2.4 异常处理与超时控制：exceptionally、handle、orTimeout 的实战姿势

CompletableFuture 的异常处理是沿着回调链条传播的，跟 try-catch 很像，但位置决定能兜住谁。exceptionally 只能处理它之前那段链上抛出的异常，and 后面的异常会继续往更后面的链上传。handle 则更全能，不管正常结果还是异常都进入这个方法，你必须返回一个结果，相当于做了一次“最终兜底”。

超时这块，Java 9 开始才有的 orTimeout 方法非常好用。它能在指定时间没完成的时候，用 TimeoutException 异常完成这个 CompletableFuture。我在实际项目里给每一个远程调用的异步任务都套了一层：

CompletableFuture<OrderVO> orderFuture = CompletableFuture .supplyAsync(() -> orderClient.query(detailReq), asyncExecutor) .orTimeout(500, TimeUnit.MILLISECONDS) .exceptionally(ex -> { log.warn("订单服务查询超时，降级返回空订单", ex); return OrderVO.empty(); });

这里有个细节，orTimeout 内部是通过一个定时任务去触发完成的，所以如果下游服务真的慢，线程池里的那条线程依然会被这个慢请求占住，超时只是让你“不等待”了，不能阻断线程正在做的事。这个特性在面试里也是一道不错的追问点。

3. Phaser：动态阶段协调器

3.1 Phaser 的使用场景

先说结论：Phaser 在国内互联网公司里用得不算多，但它一旦用对场景，代码会变得非常优雅。它解决的问题是“让一批线程在多个阶段上保持同步”。举个例子，你要批量处理一千个文件，每个文件需要经过“读取内容 -> 数据校验 -> 格式转换 -> 上报结果”四个阶段。如果用 CountDownLatch，你得为每个阶段准备一个计数器，主线程再反复 await，代码很绕。而 Phaser 可以把这四个阶段定义成一到多个 Phaser 实例，每个工作线程在每个阶段之后统一调用 arriveAndAwaitAdvance，等这一批所有线程都走到这个阶段了，再一起进入下一个阶段。

另一个我见过特别适合 Phaser 的场景是分页批量入库。比如数据核对系统，一批任务分多页处理，每页几百条，每条数据要“查存量、做比对、写差异”，多线程协作处理完一页后，必须等到所有线程处理完当前页，再拉下一批数据，避免重复处理和顺序错乱。这种需求用 Phaser 的 dynamism 特性（动态注册/注销参与者）简直量身定做。

3.2 核心 API 速记：register、arrive、await 的三种组合

Phaser 的核心状态是 phase，每推进一次阶段，phase 值加一。每个线程通过 register() 或 bulkRegister(n) 注册成为参与者，最后用 arriveAndDeregister() 退出。常用的三个方法组合如下：

• arriveAndAwaitAdvance()：到达当前阶段并等待其他参与者到达。这是使用频率最高的方法。
• arrive()：只报告“我到了”，不等待，立马做自己的事。
• awaitAdvance(phase)：等待指定的阶段推进到下一阶段，通常搭配 arrive 使用。

Phaser 还支持重写 onAdvance 方法，在两个阶段切换的瞬间执行一些动作。它的返回值为 true 时，Phaser 会被终止。默认实现是当参与者数量变成 0 时返回 true，如果你想让 Phaser 一直复用，重写它返回 false 即可。一个基础例子是模拟三个线程两轮协作：

Phaser phaser = new Phaser(3); // 主线程 + 3 个工作线程 for (int i = 0; i < 3; i++) { new Thread(() -> { System.out.println(Thread.currentThread().getName() + " 开始执行阶段1"); phaser.arriveAndAwaitAdvance(); System.out.println(Thread.currentThread().getName() + " 开始执行阶段2"); phaser.arriveAndAwaitAdvance(); }, "worker-" + i).start(); }

注意，上例中主线程也在 Phaser 的参与者计数里，所以三个工作线程全部 arriveAndAwaitAdvance 以后，加上主线程一共四个参与者，如果主线程不参与等待，实际是不会推进的。这是新手最常犯的错误——默认 new Phaser(3) 只代表内部注册了三个参与者，但这三个参与者是谁、是否包含主线程，你心里要有数。

3.3 从 CountDownLatch、CyclicBarrier 到 Phaser：三者的使用边界

很多面试题爱问“CountDownLatch、CyclicBarrier、Phaser 的区别”，其实记住三句话就够：

• CountDownLatch 是一次性闸门，计数器减到 0 就不能复用，适合“一个线程等 N 个任务完成”。
• CyclicBarrier 是可循环使用的屏障，所有线程到达后同时释放，适合“固定数量线程反复对齐”。
• Phaser 是前两者的超集，支持参与者动态注册/注销，还支持阶段推进。

这里我自己的经验是：如果任务只是简单“等所有异步任务返回”，优先用 CountDownLatch 或者 CompletableFuture.allOf，不要为了用 Phaser 而用 Phaser。Phaser 真正的优势在于阶段不确定、参与者数量会变化、需要多次循环对齐的场景。一旦发现自己的业务里已经有多个 CountDownLatch 串联，那就该考虑 Phaser 了。

3.4 动态注册与自定义阶段切换的实战细节

动态注册是 Phaser 最容易被忽略但最实用的能力。比如任务处理过程中，某个工作线程发现还需要拆分出更多子任务，可以动态注册新的参与者。每个新任务进来时 register()，任务结束时 arriveAndDeregister()，Phaser 会正确感知参与人数并同步屏障。

再一个细节：在多阶段任务里，如果某个线程在第二阶段就处理完了，而其他线程还有第三、第四阶段，你必须用 arriveAndDeregister() 注销自己，否则其他线程会永远卡在 awaitAdvance，因为 Phaser 会认为还有参与者没到达。这个坑我踩过一次，线上任务直接 hang 住，排查了半天发现是一个线程在异常分支里忘了注销。所以用 Phaser 的代码里，一定要在 finally 里处理参与者注销，跟用锁要释放一个道理。

4. Spring Boot 联合实战：从配置到业务落地

4.1 线程池隔离与命名规范

Spring Boot 项目里建议把业务线程池拆成几个语义不同的池：异步任务池（处理常规 IO 操作）、批处理池（处理较重计算任务）、以及给 CompletableFuture 编排链路专用的聚合池。池与池之间互相隔离的好处是，某个下游故障导致线程池打满时，不会波及到另一个核心业务。

命名规范这块别偷懒。线程名的前缀一定要带上业务含义，比如 order-async、report-worker，排查问题时 jstack 一出来就知道是谁的线程把 CPU 跑满了。我用 ThreadPoolTaskExecutor 时还会额外设置 setWaitForTasksToCompleteOnShutdown(true) 和 setAwaitTerminationSeconds(60)，避免 Spring 容器关闭时任务被粗暴中断。

spring: task: execution: pool: core-size: 8 max-size: 16 queue-capacity: 200 keep-alive: 60s thread-name-prefix: biz-async- shutdown: await-termination: true await-termination-period: 60s

这样做的好处不只是规范，更重要的是你在后续监控告警里能一眼看出是哪个线程池出问题。我记得有一次线上告警线程数高，jstack 全部是 async-external 线程，立刻定位到是某个外部服务响应变慢导致线程池被打满，这个过程如果线程名是默认的 pool-1-thread-x，排查难度直接翻倍。

4.2 实战场景一：多服务并行调用聚合

电商详情页是一个经典场景，需要聚合商品基础信息、实时库存、营销活动、物流模板四个数据源。这四个数据源互相独立，串行调用可能要 800 毫秒，用 CompletableFuture 并行聚合可以压到 250 毫秒左右。下面是我在实际项目里精简过的代码：

public ProductDetailVO getProductDetail(String productId) { CompletableFuture<ProductBase> baseFuture = CompletableFuture .supplyAsync(() -> productService.getBase(productId), asyncExecutor) .orTimeout(300, TimeUnit.MILLISECONDS) .exceptionally(ex -> ProductBase.empty()); CompletableFuture<StockVO> stockFuture = CompletableFuture .supplyAsync(() -> stockService.getStock(productId), asyncExecutor) .orTimeout(300, TimeUnit.MILLISECONDS) .exceptionally(ex -> StockVO.empty()); CompletableFuture<ActivityVO> activityFuture = CompletableFuture .supplyAsync(() -> activityService.getActivity(productId), asyncExecutor) .orTimeout(300, TimeUnit.MILLISECONDS) .exceptionally(ex -> ActivityVO.empty()); CompletableFuture<LogisticsVO> logisticsFuture = CompletableFuture .supplyAsync(() -> logisticsService.getTemplate(productId), asyncExecutor) .orTimeout(300, TimeUnit.MILLISECONDS) .exceptionally(ex -> LogisticsVO.empty()); CompletableFuture.allOf(baseFuture, stockFuture, activityFuture, logisticsFuture).join(); ProductDetailVO detailVO = new ProductDetailVO(); detailVO.setBase(baseFuture.getNow(null)); detailVO.setStock(stockFuture.getNow(null)); detailVO.setActivity(activityFuture.getNow(null)); detailVO.setLogistics(logisticsFuture.getNow(null)); return detailVO; }

这段代码的精髓在于，四个子任务互不阻塞地并行执行，然后 where 主线程只在最后 join 一次，整体耗时约等于最慢的那个子任务耗时。同时每个子任务都做了超时 + 降级，任何一个下游挂了都不会拖垮整个详情页。我在给团队做分享时反复强调，这种并行聚合的写法必须附带超时和降级，否则一旦下游服务变慢，接口 P99 会直接飙红。

4.3 实战场景二：用 Phaser 实现分阶段批量任务

这个场景是真实业务里的一个数据补偿任务：有一批订单数据需要先校验、再计算、最后落库。为了不让数据库连接数爆炸，我按批次处理，每批 100 条，用 8 个线程并行处理。每一批里，8 个线程各自从队列拿数据，处理完当前阶段后必须等到批次内所有线程都完成，再统一进入下一阶段。Phaser 的 register 在这种场景下正好配合动态子任务拆分的需求：

Phaser phaser = new Phaser(1); // 主线程注册 int batchSize = 8; ExecutorService executor = Executors.newFixedThreadPool(batchSize); try { for (int i = 0; i < batchSize; i++) { phaser.register(); executor.submit(() -> { boolean work = true; try { while (work) { OrderTask task = queue.poll(); if (task == null) { work = false; } else { validate(task); phaser.arriveAndAwaitAdvance(); // 等待校验阶段完成 calculate(task); phaser.arriveAndAwaitAdvance(); // 等待计算阶段完成 persist(task); } } } finally { phaser.arriveAndDeregister(); // 线程退出，注销参与者 } }); } phaser.arriveAndDeregister(); // 主线程退出，让8个工作线程完全接管 } finally { executor.shutdown(); }

这个例子里最关键的就是 finally 里的 arriveAndDeregister()。因为如果某个线程在 validate 阶段抛异常提前退出，不注销自己的参与者名额，其他工作线程将永久阻塞在 arriveAndAwaitAdvance 上。这种“卡死”的问题是 Phaser 使用中最隐蔽也最可怕的，代码 review 时必须盯着所有退出路径。

4.4 实战场景三：异步下单编排的骨架设计

下单接口比详情页复杂，因为步骤之间存在依赖关系：先校验库存和风控（并行），然后扣减库存、生成订单（依赖前面通过），再发 MQ 消息做后续异步处理。这种依赖关系用 CompletableFuture 可以做得非常清晰：

CompletableFuture<Void> stage1 = CompletableFuture.allOf( CompletableFuture.runAsync(this::checkStock, asyncExecutor), CompletableFuture.runAsync(this::checkRisk, asyncExecutor) ); CompletableFuture<OrderDO> stage2 = stage1.thenApply(v -> { // 第一阶段通过后，再执行扣库存和生成订单 boolean deducted = inventoryService.deduct(); if (!deducted) { throw new BizException("库存不足"); } return orderService.createOrder(); }); stage2.thenCompose(order -> CompletableFuture.runAsync(() -> mqSender.send(order), asyncExecutor)) .exceptionally(ex -> { log.error("异步下单编排失败", ex); // 补偿逻辑：回滚库存、记录失败订单 return null; });

这里整个编排没有显式 join，主线程只负责把各阶段串起来，异常会顺着链条往下走，最后由 exceptionally 做统一兜底。实际开发中，如果第二阶段失败需要回滚库存，我建议在补偿逻辑里加一个幂等键，因为异步失败后可能会有重试，幂等键能保证补偿操作只执行一次。

4.5 Spring Boot 3.2 之后的一个隐藏坑：ExecutorService Bean 的自动关闭

这个坑非常新，很多人还不知情：Spring Boot 3.2 开始，容器在关闭时会自动调用 ExecutorService 相关 Bean 的 shutdown 方法。也就是说，如果你在 Spring 容器里声明了一个 ThreadPoolTaskExecutor 或者 ExecutorService 类型的 Bean，应用优雅停机时 Spring 会帮你关掉线程池。这本身是好事，但也意味着你的线程池声明周期被容器接管了，如果代码里再手动执行一次 shutdown，就会抛 RejectedExecutionException。所以我的建议是：让 Spring 管理线程池 Bean，自己只做业务提交，不做池生命周期管理。

另外，Spring Boot 3.2 对虚拟线程的支持也更友好了。Java 21 中可以把 spring.threads.virtual.enabled=true 打开，容器会为每条请求创建虚拟线程。这个特性对 IO 密集型任务特别友好，因为虚拟线程开销小、可以大量创建，不过目前和 CompletableFuture 编排并不是直接替代关系——虚拟线程解决的是“线程太贵”的问题，CompletableFuture 解决的是“异步编排写起来太累”的问题，两者可以共存。

5. 常见问题与排查技巧实录

5.1 线程池被打满与拒绝策略

现象：接口偶尔报 RejectedExecutionException，或者线程池队列堆积导致延迟飙升。

排查步骤一般是：

1. 看监控面板，确认是哪个线程池的活跃线程数长期逼近 max。
2. 用 jstack 抓线程栈，看这些线程都卡在什么调用上，如果是外部 HTTP 调用的 timeout 时间太长，优先把下游超时时间调短。
3. 调整线程池参数，并观察队列容量和拒绝策略。CallerRunsPolicy 适合不想丢任务的场景，AbortPolicy 适合对实时性要求高、宁可失败也不要堆积的场景。

经验值方面，响应式服务里的线程池参数真的不是拍脑袋定的，建议先用压测工具跑一轮，把 P99 和吞吐量拉个曲线再定。

5.2 回调不执行或结果莫名丢失

这里有个经典原因：在回调链中不小心用了 thenApply 而不是 thenApplyAsync，且上一个任务已经完成，那么回调会在提交线程（比如主线程）里执行，导致主线程意外承担了耗时逻辑。反过来，用了 thenApplyAsync，它会走默认的 ForkJoinPool.commonPool，加锁或长时间阻塞 commonPool 的线程会让并行流也受影响。所以排查时先看回调是否被建到了正确的线程池里。

还有一个坑是异常被“吞掉”。如果你使用了 exceptionally，但异常发生时你的降级逻辑没有记录日志，那异常就被静默处理了。所以我建议在所有降级方法里至少打一条 warn 日志，并且尽量带上任务标识，方便链路追踪。

5.3 Phaser 线程永久卡住

Phaser 卡住的常见原因只有一个：参与者数量没对齐，有人到到了但没人注销，或者有人一直没到。排查时可以在 Phaser 的每次 arriveAndAwaitAdvance 前后打印当前 phase 和 registeredParties，用日志快速判断是谁缺位。另一个技巧是给 Phaser 调用加上超时保护，在 awaitAdvance 返回负数（表示 Phaser 已终止）时进行告警。我甚至见过有人直接用 phaser.isTerminated() 做健康检查的，虽然有点粗暴，但确实能快速暴露问题。

5.4 好好的 Phaser 为什么被标记弃用

这个必须提醒大家：在 JDK 19 中，Phaser 被标记为“for removal”，虽然 JDK 21 里还没有真正移除，但官方态度已经很明确了。原因不是 Phaser 有 bug，而是它的使用率比较低，而且大部分场景可以被 CompletableFuture、虚拟线程或者更专门的结构体替代。所以如果你准备在全新的生产项目里用 Phaser，我建议谨慎一点，至少做一个版本兼容评估。相对而言，CompletableFuture 是官方重点演进的方向，New CompletableFuture 相关特性还在持续改进，比如 JDK 9 的 orTimeout、JDK 12 的新 Thread 等，优先级更高。

5.5 线程隐患速查表

6. 面试考点串讲与学习路线建议

6.1 CompletableFuture 高频面试题

面试问到 CompletableFuture，常见的有这么几道：get 和 join 的区别是什么？哪个会包装异常？答案：两者都会阻塞等待，但 get 会抛受检异常 ExecutionException 和 InterruptedException，join 抛的是 CompletionException，是不受检异常，通常更省事。completeExceptionally 有什么作用？它能让一个 CompletableFuture 在未被任务填充的情况下以异常状态完成，是实现超时控制的关键一环。thenApply 和 thenCompose 有什么区别？thenApply 返回嵌套结构，thenCompose 做扁平化，回到 CompletableFuture 本身。这些问题答清楚，基本能证明你真的用过，不只是背过 API。

6.2 Phaser 面试题怎么答

面试官一般不会问特别深的 Phaser，但会用它区分有没有真正读过 JUC 源码。我会这样答：Phaser 可以看成是 CountDownLatch 和 CyclicBarrier 的升级版，支持参与者动态注册和注销，内部用 CAS 维护一个 state 变量，同时包含 phase 和 parties 两个信息。然后举一个分阶段并发任务的例子，说明 onAdvance 的阶段切换逻辑和返回 true 时终止的特性。如果能提到“它已被标记弃用，所以生产环境我会优先考虑 CountDownLatch 或者 CompletableFuture 替代方案”，会显得你的知识体系是跟得上官方演进的，这个加分项很实际。

6.3 虚拟线程对并发生态的影响

2025 年的 Java 面试已经绕不开虚拟线程了。如果被问到，我建议从“虚拟线程是什么”、“它怎么解决阻塞问题”、“哪些场景不适合”三个维度讲。虚拟线程适合大量阻塞在 IO 上的任务，比如每个请求都要调远程服务；但不适合 CPU 密集型的计算任务，也不适合持有 synchronized 或 native 调用的场景。这里有一个更细致的认知：虚拟线程让并发编程更简单，很多原本需要 CompletableFuture 做的异步化可以改为同步代码虚拟线程，但代价是失去了一些结构化并发带来的编排能力和超时降级的灵活性。所以在我的实践里，两者往往混合使用，同步编排交给 CompletableFuture，长链路 IO 任务直接丢给虚拟线程执行器。

到这里，CompletableFuture 和 Phaser 的原理、API、Spring Boot 落地和面试串讲就差不多了。最后我想说点掏心窝的话：并发编程最怕的不是不会用 API，而是没有建立“谁来等、谁先走、谁负责补位”的意识。CompletableFuture 教会我的是“让数据流推着代码走”，Phaser 教会我的是“多个线程之间如何对齐节奏”。这两个工具在真实项目里并不冲突，反而常放在一起用。如果你刚接触这块，别急着背八股，先拿一个线上慢接口练手，把串行改并行，把 Future 改 CompletableFuture，再找批处理任务试试 Phaser，踩几轮坑之后，你会发现很多并发工具的 API 只是表象，背后那套“协调一堆任务”的思想才是真正值钱的东西。