虚拟线程环境下熔断器适配问题及解决方案咨询

我们的应用基于Spring Boot 3.2，运行在JDK 21环境中，已全面采用虚拟线程——Tomcat请求处理、@Async注解均使用虚拟线程池。但当端点调用被非虚拟线程池执行的代码时，仍会出现线程竞争问题：比如请求处理器调用被CircuitBreaker.run()包裹的代码时，Resilience4J默认使用核心数限制的平台线程池，导致100个虚拟线程请求竞争4个平台线程，严重限制了虚拟线程的扩展性。

增加Resilience4J线程池规模虽能缓解问题，但无法实现全虚拟线程的扩展性，完全抵消了虚拟线程的优势；替换其线程池则因Resilience4J存在synchronized等Loom不友好问题（易引发线程固定），且官方未适配虚拟线程，存在维护风险。

现咨询两个问题：

1. 是否存在适配虚拟线程的熔断器实现？现有实现是否在推进Loom友好性适配？
2. 还有哪些未考虑的解决方案？自行实现简单熔断器并在独立虚拟线程运行是否可行（需支持虚拟线程抢占）？

补充：请求处理器通常从缓存获取数据，仅缓存失效时才执行熔断器保护的代码，因此混合了短耗时（数毫秒）与长耗时（数十秒）场景，虚拟线程优势显著。

问题解答 #

1. 适配虚拟线程的熔断器实现及Loom适配进展 #

• 现有适配选项：
  • 轻量级熔断器Failsafe已完成Loom适配，内部避免了线程固定问题，支持直接在虚拟线程中运行，核心逻辑未使用synchronized等绑定平台线程的代码；
  • Spring Cloud Circuit Breaker底层可结合Resilience4J的最新快照版本，社区正在推进移除阻塞性锁，替换为Loom友好的并发控制方式（如StampedLock或无锁结构）；
  • Hystrix的后续替代项目Hystrix Reactive基于Reactor非阻塞模型，天然适配虚拟线程异步执行模式，可通过publishOn指定虚拟线程调度器实现无阻塞执行。
• 官方适配进展：Resilience4J社区已将Loom适配列为高优先级任务，当前已有多个PR处理线程固定问题，预计未来minor版本会正式支持虚拟线程；Spring框架的Resilience4JCircuitBreakerFactory也在跟进调整，以更好集成虚拟线程池。

2. 其他解决方案及自行实现的可行性 #

• 未考虑的解决方案：
  • 临时调整Resilience4J线程池为虚拟线程池：自定义ThreadPoolBulkhead，使用Executors.newVirtualThreadPerTaskExecutor()作为底层线程池，同时确保熔断器保护的代码块不使用synchronized等阻塞操作，仅在缓存失效的长耗时场景中使用，可降低线程固定概率；
  • 用Reactor封装熔断器逻辑：将受保护代码包装为Reactor异步任务，通过Mono.fromCallable()结合publishOn(Schedulers.virtual())切换到虚拟线程执行，利用非阻塞特性规避平台线程池限制；
  • Spring AOP实现轻量级熔断器：借助AOP拦截方法调用，自行实现熔断器状态机（关闭/打开/半开），拦截逻辑直接在请求的虚拟线程中执行，无需额外线程池，完全适配虚拟线程扩展性。
• 自行实现简单熔断器的可行性：完全可行，但需注意两点：
  • 状态机线程安全：用原子类（如AtomicInteger、AtomicReference）实现状态切换和失败计数，避免使用synchronized引发线程固定；
  • 虚拟线程抢占支持：虚拟线程由JVM调度，无需手动实现抢占逻辑，只要熔断器逻辑不阻塞平台线程，JVM即可自动调度虚拟线程，实现高效抢占；同时针对混合场景，可在缓存命中时直接跳过熔断器逻辑，长耗时场景触发状态判断，最大化虚拟线程优势。

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