Spring Boot中WebClient调用block()时Unsafe.park耗时过长问题求助

问题背景 #

在Spring Boot应用中使用WebClient同步调用远程服务时，调用block()方法等待响应出现间歇性的Unsafe.park执行耗时过长（甚至超过1分钟）的情况，后续调用延迟持续增加，疑似与线程竞争或死锁相关，主线程会被无限期park，导致应用严重延迟。简化代码如下：

Root uploadedFile = WebClient.builder().build().post().uri(uri)
        .contentType(MediaType.APPLICATION_JSON)
        .header("Authorization", apiKey)
        .body(BodyInserters.fromMultipartData(map))
        .retrieve()
        .bodyToMono(Root.class)
        .block(); // <-- 问题发生位置

WebClient block() 已知问题 #

• 线程池资源耗尽：WebClient默认依赖的Reactor Netty EventLoop线程池是为IO密集型场景设计的，若block()调用占用过多EventLoop线程，会导致后续请求排队等待，进而引发Unsafe.park时长激增。
• 上下文传播冲突：应用中存在ThreadLocal上下文（如日志MDC、请求上下文）时，block()可能因上下文传播不当导致线程状态异常，间接触发park异常。
• 调度器配置不合理：自定义调度器若核心线程数过少、队列满额，block()会触发调度器内部线程竞争，延长park等待时间。
• 远程服务异常：远程服务超时、半开连接或响应不完整时，Reactor异步回调无法正常触发，block()会进入无限等待状态，表现为Unsafe.park耗时过长。

最佳实践 #

• 禁止在IO线程中调用block()：绝对不要在Reactor EventLoop线程（如WebFlux请求处理线程）中调用block()，避免阻塞IO线程导致线程池耗尽。若必须同步调用，需切换到专门的阻塞线程池：

  Root uploadedFile = WebClient.builder().build().post().uri(uri)
          .contentType(MediaType.APPLICATION_JSON)
          .header("Authorization", apiKey)
          .body(BodyInserters.fromMultipartData(map))
          .retrieve()
          .bodyToMono(Root.class)
          .publishOn(Schedulers.boundedElastic())
          .block(Duration.ofSeconds(30));
  

• 复用WebClient实例：不要每次请求都创建新的WebClient，重复创建会导致连接池和线程资源过度消耗，加剧线程竞争。应将WebClient配置为单例Bean：

  @Bean
  public WebClient webClient() {
      return WebClient.builder().build();
  }
  

• 强制设置block()超时：永远不要无限制等待，给block()配置合理的超时时间，避免主线程被无限期park。
• 优先使用异步调用：WebClient的设计初衷是异步非阻塞，尽量使用subscribe()配合回调或反应式编程流程，避免同步阻塞调用。

排查建议 #

• 抓取线程栈分析：问题出现时，用jstack或Arthas抓取线程栈，查看被park线程的状态，确认是否存在锁未释放、EventLoop线程被阻塞的情况，重点关注调用block()的线程栈信息。
• 监控线程池状态：通过Micrometer等工具监控Reactor Netty EventLoop线程池、boundedElastic线程池的活跃线程数、队列大小、任务等待时间，确认是否存在资源耗尽。
• 检查远程服务状态：排查远程服务是否存在超时、响应缓慢、连接泄漏问题，用抓包工具分析请求响应全流程，确认是否有请求丢失或响应延迟。
• 验证上下文传播：检查应用中ThreadLocal的使用情况，打印block()前后的ThreadLocal值，确认上下文是否正确清理或传播。
• 排查Reactor版本：部分旧版本Reactor/Reactor Netty存在block()相关bug，尝试升级到稳定版本（如Reactor 2020.0.x及以上）。

解决建议 #

• 重构为异步调用：调整代码逻辑，使用反应式编程流程，比如在Spring WebFlux中直接返回Mono<Root>，彻底避免同步阻塞。
• 配置专用阻塞线程池：若必须同步调用，使用Schedulers.boundedElastic()或自定义阻塞线程池，确保IO线程不被占用：

  @Bean
  public Scheduler customBlockingScheduler() {
      return Schedulers.newBoundedElastic(10, 100, "custom-blocking-pool");
  }
  

  调用时指定该调度器：

  .publishOn(customBlockingScheduler)
  .block(Duration.ofSeconds(30));
  

• 优化WebClient连接池：调整Reactor Netty连接池参数，避免连接耗尽：

  @Bean
  public WebClient webClient() {
      HttpClient httpClient = HttpClient.create()
              .poolResources(PoolResources.fixed("webclient-pool", 50))
              .responseTimeout(Duration.ofSeconds(10));
      return WebClient.builder()
              .clientConnector(new ReactorClientHttpConnector(httpClient))
              .build();
  }
  

• 添加超时与重试机制：在WebClient调用中配置超时和重试，避免因远程服务异常导致无限等待：

  .retrieve()
  .bodyToMono(Root.class)
  .timeout(Duration.ofSeconds(15))
  .retryWhen(Retry.backoff(3, Duration.ofSeconds(1)))
  .publishOn(Schedulers.boundedElastic())
  .block(Duration.ofSeconds(20));
  

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