Spring Boot WebFlux环境下WebClient集成OAuth2客户端并发请求触发超时问题

• 响应式栈违规使用block()导致事件循环阻塞
  WebFlux基于非阻塞事件循环模型，默认事件循环线程数与CPU核心数对齐，所有请求的IO调度、响应返回都依赖这部分核心线程执行。在业务代码路径上的.block()操作会直接占用事件循环线程并阻塞长达请求等待的全流程，单请求场景下因为没有并发冲突不会暴露问题，当并发数达到10个以上时，所有事件循环线程被阻塞占满，后续请求无法获得调度执行权，最终触发配置的10s超时。
  同时代码中链式调用的.share()属于冗余操作，对当前单WebClient请求的响应获取没有实际作用，反而会增加不必要的流订阅管理开销。
• OAuth2授权客户端的并发处理缺陷
  当前配置的AuthorizedClientServiceReactiveOAuth2AuthorizedClientManager默认实现下，当多并发请求同时检测到访问令牌过期、需要刷新或重新获取时，会独立发起多次完全重复的令牌获取请求，不会做并发结果复用。这会导致两个问题：一是授权服务器端的请求压力陡增，响应延迟上升；二是客户端侧的请求队列被授权流程的耗时占满，最终拖慢全链路响应。
• WebClient默认连接池参数不匹配并发量
  WebClient底层基于Reactor Netty实现，默认针对单目标服务的最大连接数为CPU核心数 * 2，当并发请求数超过这个阈值时，新的请求会进入连接等待队列，默认等待超时时间为10s，与配置的WebClient请求超时时间刚好重合，极易触发超时异常。

• 全链路移除block()操作：WebFlux的接口实现必须保持全响应式链路，将当前的WebClient调用结果直接以Mono<String>的形式返回给上层调用方，不要在业务方法内做阻塞取值，从根源上避免事件循环线程被占用。
• 优化OAuth2客户端的并发复用逻辑：在AuthorizedClientServiceReactiveOAuth2AuthorizedClientManager的配置中，开启同一客户端ID下的令牌获取请求并发共享，保证同一时间点同一注册ID下只有一个请求会向授权服务器发起令牌获取/刷新请求，其余并发请求直接等待共享的请求结果返回，消除重复的授权请求开销。
• 按需调整WebClient连接池配置：根据实际峰值并发量配置Reactor Netty连接池参数，将目标服务的最大连接数调整为峰值并发的1.2倍，同步调整连接等待队列的超时时间，避免连接数不足导致的排队超时。
• 阻塞操作隔离调度：如果业务流程中确实存在无法改造的同步阻塞逻辑（比如老旧SDK调用、JDBC操作），必须将这部分逻辑切换到独立的弹性调度线程池执行，绝对不能让阻塞操作运行在WebFlux的事件循环线程上。

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