使用whenComplete记录CompletableFuture的结果与错误是否是行业最佳实践？

一、whenComplete用于日志记录是否为通用最佳实践 #

仅做日志记录的场景下，whenComplete是行业内非常常用的实现方式，本身完全匹配需求，不算不合理，但要注意几个容易踩的坑：

• whenComplete的回调逻辑里不要写除了日志打印之外的业务逻辑，尤其要避免回调自身抛出异常：一旦回调抛错，会覆盖原异步任务的异常，导致上层拿到的异常不是真实的业务异常
• 你示例代码中使用了默认的ForkJoinPool.commonPool()，生产环境不建议直接用公共线程池，所有异步任务共用公共池容易出现资源争抢、影响核心业务执行的问题，建议绑定自定义的业务线程池
• 如果只需要记录异常不需要记录成功结果，也可以用exceptionally代替，两种写法都符合规范，按需选择即可

二、更规范的实现参考 #

如果要优化你给出的示例代码，可以调整为如下写法：

// 先注入自定义配置的线程池，或者用Spring管理的线程池
@Resource
private ThreadPoolTaskExecutor myBusinessThreadPool;

void function() {
   CompletableFuture
     .runAsync(() -> runAsyncfunction(), myBusinessThreadPool)
     .whenComplete((result, err) -> {
         if (err != null) {
             log.error("异步任务执行失败", err);
             return;
         }
         log.info("异步任务执行成功, 结果:{}", result);
      });
}

三、Spring Boot原生支持的相关能力 #

Spring Boot针对异步任务场景有成熟的原生支持，不用全部手动写CompletableFuture逻辑：

• @Async注解：给需要异步执行的方法加上@Async注解，直接返回CompletableFuture即可，不需要手动调用runAsync/supplyAsync，框架会自动帮你提交到线程池执行
• 全局线程池配置：可以在application.yml里通过spring.task.execution开头的配置项统一配置默认异步线程池的核心线程数、队列长度、拒绝策略等参数，也可以自定义多个线程池Bean，在@Async("线程池Bean名称")里指定使用
• 全局异步异常处理：如果需要统一处理所有异步方法的异常，不用每个任务都写whenComplete，可以实现AsyncUncaughtExceptionHandler接口，重写异常处理逻辑统一打印日志，框架会自动捕获所有@Async方法抛出的未捕获异常走这个处理逻辑

内容的提问来源于stack exchange，提问作者Java Programmer