WebFlux中Mono.fromFuture调用不一致排查及默认线程池咨询

一、指标计数不匹配问题调试步骤 #

• 验证Mono的订阅状态：WebFlux中Mono是惰性执行的，只有被订阅后内部逻辑才会触发。你上报metric-1后创建了Mono.when，但如果该Mono未被上层正确订阅（比如全局过滤器截断、响应提前结束），就会出现metric-1计数远高于metric-2/metric-3的情况。可以在Mono.when后添加doOnSubscribe上报新指标（如metric-4），对比metric-1和metric-4的差值，确认未订阅请求的数量。
• 修复异常吞入导致的指标缺失：当前updateDynamoDBTable方法中onErrorResume直接返回Mono.empty()且无日志输出，可能存在异常被吞但metric-3未正确上报的情况。修改代码，先在doOnError中记录异常栈并上报metric-3，再用onErrorResume恢复流：

  private Mono<Void> updateDynamoDBTable(Event event, DynamoDbAsyncClient dynamoDbAsyncClient){
      return Mono.defer(() -> Mono.just(event))
                  .map(this::toDynamoRequest)
                  .flatMap(item -> Mono.fromFuture(dynamoDbAsyncClient.updateItem(item)))
                  .doOnNext(uir -> // 上报Datadog metric-2)
                  .doOnError(e -> {
                      log.error("DynamoDB更新失败，事件ID: {}", event.getId(), e);
                      // 上报Datadog metric-3
                  })
                  .onErrorResume(e -> Mono.empty());
  }
  

• 排查DynamoDB异步请求的触发情况：Mono.fromFuture依赖Future的执行结果，但如果dynamoDbAsyncClient.updateItem返回的Future未被正确触发（比如客户端配置错误），后续逻辑不会执行。可以在flatMap内部添加doOnSubscribe，确认每个DynamoDB请求是否被订阅执行。
• 检查指标上报的可靠性：高负载下如果指标上报是异步操作，可能因线程池耗尽、超时等导致上报丢失。可以暂时将上报改为同步操作，或给上报逻辑添加日志，确认每次上报都成功完成。
• 绑定追踪ID排查请求链路：给每个请求生成唯一trace id，将metric-1、metric-2、metric-3的上报都关联该trace id，通过日志或追踪系统匹配每个metric-1对应的后续操作，定位缺失的指标请求。

二、WebFlux默认线程池说明 #

在未自定义线程池的情况下，Spring WebFlux 5.3版本的默认线程池取决于运行环境：

• 默认Netty服务器：使用Netty的EventLoop线程池，分为boss线程（负责连接监听）和worker线程（负责IO处理），线程数默认等于CPU核心数的2倍。
• Servlet容器（如Tomcat）：使用容器提供的异步线程池，Tomcat默认异步线程池大小为200，由容器自身管理。
• 非阻塞IO操作（如DynamoDB异步调用）：默认复用上述EventLoop/容器异步线程池执行，无需额外切换线程池；若涉及阻塞操作，则需通过publishOn切换到专门的阻塞线程池避免阻塞IO线程。

内容的提问来源于Stack Exchange，提问作者Shankar