Quarkus Reactive SQL客户端如何保证API为全链路响应式

线程运行现象是否说明未实现全链路异步？ #

这个现象不代表你没有实现全链路响应式异步，核心原因如下：

• 响应式编程的核心判定标准从来不是「每个请求运行在独立专属线程上」，而是线程不会被IO操作阻塞等待，仅用少量线程即可承载大量并发请求。你观察到的所有任务都运行在同一个executor thread 0是正常现象：Reactive SQL Clients 基于Vert.x实现，默认的Event Loop线程池大小为CPU核心数*2，单条Event Loop线程本身就可以处理成千上万个并发请求，只要线程没有被阻塞卡住，就是符合响应式设计要求的。
• 你可以自行验证异步有效性：同时发起100个并发请求，每个请求执行耗时1s的数据库查询，如果总耗时接近1s而非100s，即可确认全链路非阻塞生效。

为何执行阻塞操作没有抛出错误提示？ #

这是两类组件的默认校验规则不同导致的：

• Panache Hibernate Reactive 默认集成了Quarkus的阻塞线程检测能力，只要Event Loop上的任务执行时间超过阈值就会抛出提示。
• Reactive SQL Clients 本身默认没有开启强制阻塞校验，所以就算你在调用链中加入了阻塞逻辑（比如Thread.sleep、同步文件IO等），也不会主动抛出错误。

如果需要开启阻塞检测，可以在application.properties中添加如下配置：

# 阻塞线程检测间隔，单位毫秒
quarkus.vertx.event-loops.blocked-thread-check-interval=100
# Event Loop线程单次任务最大执行时长，超过即输出警告
quarkus.vertx.event-loops.max-event-loop-execute-time=2000

额外注意事项 #

• 即便没有错误提示，也不要在Reactive SQL Clients的调用链中加入阻塞逻辑，否则会卡住整条Event Loop线程，影响该线程上承载的所有请求
• 确有阻塞逻辑需要执行时，要主动将阻塞逻辑提交到Worker线程池处理，不要占用Event Loop线程资源

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