REST客户端标注Fault tolerance @Asynchronous引发Open Liberty异常及兼容性咨询

核心问题根源 #

你遇到的Windows下核心转储、MacOS下instrument断言错误，本质是在已返回CompletionStage的REST客户端方法上叠加使用MicroProfile Fault Tolerance的@Asynchronous注解，导致了双重异步包装冲突。

关于@Asynchronous的使用疑问 #

先直接回答你的问题：对于已通过CompletionStage实现异步的REST客户端方法，不应该使用@Asynchronous注解。

原因是：

• MicroProfile Fault Tolerance的@Asynchronous设计初衷是将同步方法转换为异步执行，它会自动把方法的返回值包装成CompletionStage。
• 而你的REST客户端方法已经天然返回CompletionStage<Response>，属于原生异步方法。此时再添加@Asynchronous，会让Open Liberty的Fault Tolerance实现尝试对已经是异步的结果再次包装，触发了JVM instrument层的内部断言失败（也就是你看到的java.lang.instrument ASSERTION FAILED错误），甚至在Windows下引发核心转储。

至于@Timeout、@Retry等注解能正常工作，是因为这类注解是针对方法的执行逻辑控制（比如超时重试、熔断），不管方法本身是同步还是异步，都能适配CompletionStage的异步执行流程，不会产生包装冲突。

正确的处理方式 #

1. 直接移除REST客户端方法上的@Asynchronous
   你的方法已经返回CompletionStage，本身就是异步执行的，不需要Fault Tolerance额外做异步转换。修改后的客户端接口：

   @ApplicationScoped
   @RegisterRestClient(baseUri = "https://postman-echo.com")
   public interface TestingClient {
       @GET
       @Path("delay/4")
       @Consumes(value = MediaType.APPLICATION_JSON)
       CompletionStage<Response> doesItCrashWithDelay(String dummyData);
   }
   

2. 如果需要Fault Tolerance的异步控制，封装到CDI Bean中
   如果你确实需要借助@Asynchronous的特性（比如线程池控制），可以像你发现的临时方案那样，把REST客户端的调用封装到单独的CDI Bean中，在Bean的方法上添加@Asynchronous：

   @ApplicationScoped
   public class TestingService {
       @Inject
       @RestClient
       private TestingClient testingClient;
   
       @Asynchronous
       public CompletionStage<Response> callDelayedEndpoint(String dummyData) {
           return testingClient.doesItCrashWithDelay(dummyData);
       }
   }
   

   这种方式符合MicroProfile规范的设计，也能避免冲突。

关于博客内容的补充说明 #

你提到的Open Liberty博客中说“REST客户端接口应支持容错注解”，这里的支持指的是@Retry、@Timeout、@CircuitBreaker这类业务逻辑控制注解，而非@Asynchronous这种执行模式转换注解——因为REST客户端本身已经原生支持异步返回CompletionStage，不需要再通过@Asynchronous二次转换。

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