Java异步编程：whenComplete内的Future需调用join()吗？

在服务端点中新增邮件发送逻辑时，因为不需要等待邮件发送完成即可向用户返回响应，因此在Future链式调用的末尾添加.whenComplete()回调，在回调内调用邮件服务。该邮件服务本身是异步实现，返回值类型为CompletionStage<Void>。
初始实现代码如下：

CompletionStage<SomeResponse> someEndpoint() {
  return doThings()
      .thenApply(things -> {
        return someResponseFormat(things);
      })
      .whenComplete((someResponse, ex) -> {
        if (ex == null) {
          emailClient.sendEmail(someResponse); // 方法返回CompletionStage<Void>
        }
      });
}

• 是否需要对sendEmail(...)的返回值调用join()或get()方法？
• 调用join()/get()和不调用这两个方法，存在哪些行为差异？
• 该场景下的最佳实践是什么？
  注：核心疑问为「是否有必要调用join()/get()二者中的任意一个」，而非两个方法之间该如何选择。

不调用join()/get()的表现 #

现有裸调sendEmail且不处理返回值的写法，只会触发邮件发送任务的提交，完全不会等待邮件任务执行完成，存在两个明确的问题：

• 异常完全丢失：如果邮件发送过程中出现网络错误、鉴权失败、服务超时等异常，因为当前链路没有持有邮件任务的CompletionStage引用、也没有绑定任何异常处理逻辑，异常只会落到异步线程的全局异常处理器上，通常只会输出一条无业务关联的底层日志，很容易被忽略，导致线上出现大量邮件发送失败却长期无人感知的问题。
• 任务丢失风险：如果服务实例在邮件异步任务执行完成前触发重启、缩容、停机回收，未执行完的邮件任务会被直接丢弃，没有任何兜底机会。且因为主请求链路已经返回成功，用户侧完全感知不到邮件未送达的问题。

调用join()/get()的表现 #

如果在whenComplete回调内对sendEmail返回的CompletionStage调用join()/get()，会直接阻塞当前执行回调的线程，直到邮件发送任务成功完成或抛出异常：

• 唯一的好处是可以感知到邮件发送的异常，不会完全吞掉错误；
• 但这种写法完全违背了「不等待邮件发送就返回响应」的设计初衷：whenComplete回调执行完成前，整个接口返回的CompletionStage不会被标记为完成，接口响应耗时会直接和邮件服务的耗时绑定，一旦邮件服务出现慢请求、超时，接口会直接被拖慢甚至触发超时。更严重的是，如果回调线程和被等待的邮件任务共用同一个线程池，很容易触发线程池死锁——所有回调线程都被阻塞等待邮件任务执行，但没有空闲线程可以运行邮件任务，最终整个异步链路完全卡死。

1. 绝对不要在whenComplete这类回调中调用join()/get()这类阻塞方法，既不符合异步设计的初衷，也存在死锁风险。
2. 不要直接丢弃sendEmail返回的CompletionStage，必须为其单独绑定异常处理逻辑，记录失败日志、配置告警，必要时将失败任务投递到重试队列做兜底，避免异常静默丢失。参考实现如下：

   CompletionStage<SomeResponse> someEndpoint() {
     return doThings()
         .thenApply(things -> someResponseFormat(things))
         .whenComplete((someResponse, ex) -> {
           if (ex == null) {
             // 单独处理旁路邮件任务的异常，不阻塞主链路
             emailClient.sendEmail(someResponse)
                 .exceptionally(emailEx -> {
                   log.error("业务{}关联的通知邮件发送失败", someResponse.getBizId(), emailEx);
                   // 可在此处加入失败告警、重试队列投递等兜底逻辑
                   return null;
                 });
           }
         });
   }
   

3. 如果服务运行在容器、微服务托管环境中，最好将这类旁路异步任务提交给框架统一管理的线程池/任务调度组件，配置合理的停机等待时长、任务拒绝策略，避免服务停机时未执行完的任务被直接丢弃。
4. 需要明确：调用返回CompletionStage的异步方法时，方法本身只会触发任务提交，不会自动等待任务执行。返回的CompletionStage只是异步任务的结果句柄，如果不对这个句柄绑定后续处理逻辑，该任务的成功、失败、执行进度都和当前调用链路完全无关。

内容的提问来源于stack exchange，提问作者Andrew Cheong