Quarkus+Mutiny如何异步执行阻塞代码并让HTTP请求立即返回

你确实误解了runSubscriptionOn的作用，以及Quarkus对返回Uni类型接口的处理逻辑：

• runSubscriptionOn仅决定Uni的订阅逻辑（也就是你代码里的myService.timeConsumingMethod调用）运行在哪个线程，不会改变「返回的Uni必须完成后才会生成HTTP响应」的规则
• 你之前的写法把执行耗时任务的Uni作为接口返回值，Quarkus的HTTP扩展会自动订阅这个Uni，等待它输出结果或者抛出异常后才会给客户端返回响应，所以不管你把任务放到哪个线程执行，请求都会一直挂起直到任务结束。

实现「立即返回202+异步处理任务」的方案 #

你需要做的是手动触发耗时任务的异步执行，不要把任务对应的Uni作为接口返回值，直接返回202状态即可。注意不要自行创建线程池，直接用Quarkus托管的ManagedExecutor避免资源泄漏：

@Inject
MyService myService;
// 注入Quarkus托管的公共线程池
@Inject
ManagedExecutor managedExecutor;

@Funq("api/report")
public Uni<Response> sendReport(MyRequest request) {
    // 手动触发异步任务，无需等待执行结果
    Uni.createFrom().item(() -> myService.timeConsumingMethod(request))
        .runSubscriptionOn(managedExecutor)
        // 配置任务成功、失败的回调逻辑，比如发邮件通知
        .subscribe().with(
            result -> sendSuccessEmail(request.getUserEmail(), result),
            error -> handleTaskFailure(request.getUserEmail(), error)
        );

    // 直接返回202 Accepted，不需要等待上面的任务完成
    return Uni.createFrom().item(Response.accepted().build());
}

首先纠正一个误解：如果没有显式配置，直接写return Uni.createFrom().item(() -> myService.myIOBlockingMethod(request))不会自动切到工作线程运行，阻塞代码会直接在IO线程执行，会触发Quarkus的阻塞线程警告，严重时会拖垮整个服务的吞吐量。之前认为「IO阻塞方法自动在工作线程运行」是错误的，只有你给方法加了@Blocking注解，Quarkus才会自动把请求调度到工作线程处理。

这种写法的弊端 #

如果不加runSubscriptionOn直接把阻塞方法包进Uni.createFrom().item，本质就是在IO线程执行阻塞逻辑，会导致IO线程被占用，无法处理其他请求，服务吞吐量会急剧下降。如果加了runSubscriptionOn切工作线程，会有极微小的线程切换开销，但这个开销相比于阻塞IO线程的影响几乎可以忽略，不会导致响应时间明显变长。

最佳实践 #

分场景处理即可，不需要强行把所有阻塞方法都改成返回Uni：

• 若业务逻辑是CPU密集型，或者只有阻塞的IO客户端可用：直接给接口方法加@Blocking注解，Quarkus会自动把整个请求调度到工作线程运行，不需要你手动包装Uni，也不需要手动处理线程切换，代码复杂度最低。
• 若业务逻辑是IO密集型：优先使用对应组件的响应式客户端（比如Hibernate Reactive、Vert.x Web Client等），这些客户端原生返回Uni/Multi类型，不会阻塞任何线程，性能最优。如果实在只能用阻塞客户端，再将阻塞逻辑包装为Uni并显式指定runSubscriptionOn到托管线程池运行。

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