在 quarkus 中，即使不引入 reactive 扩展（如 `quarkus-reactive-postgresql-client`），应用仍可正常使用传统阻塞式 i/o；此时请求会被自动调度到工作线程池执行，主线程（如 netty 事件循环）保持非阻塞，保障整体吞吐能力。
Quarkus 的核心设计哲学是“响应式内核，编程自由”。其底层基于 Vert.x 和 Netty 构建了高性能、非阻塞的 I/O 运行时，但这一特性对开发者是透明且可选的——你完全不必编写 Uni、Multi 或响应式流代码。
当你使用传统阻塞 API（例如 quarkus-jdbc + JDBC 驱动、RestClient 同步调用、或 Spring-style @Transactional 服务），Quarkus 会自动将该操作提交至内置的 worker thread pool（默认为 CPU 核心数 × 2 的 IO 密集型线程池），从而避免阻塞事件循环线程（如 vert.x-eventloop-thread）。这意味着：
- ✅ HTTP 请求处理仍由非阻塞线程高效分发；
- ✅ 阻塞 I/O（如数据库查询、HTTP 调用）被安全卸载到专用工作线程；
- ✅ 你可继续使用熟悉的 try-catch、for 循环、同步事务等 imperative 编程范式；
- ❌ 不会因单个慢查询拖垮整个 HTTP 处理器（只要线程池配置合理）。
例如，以下标准 JDBC 代码在 Quarkus 中完全合法且高效：
@Path("/books")
public class BookResource {
@Inject
SqlSessionFactory sqlSessionFactory;
@GET
@Produces(MediaType.APPLICATION_JSON)
public List<Book> listBooks() {
try (SqlSession session = sqlSessionFactory.openSession()) {
return session.selectList("selectBooks"); // 阻塞 JDBC 调用
}
}
}⚠️ 注意事项：
- 避免在 REST 端点中直接调用大量耗时阻塞操作（如大文件读写、无超时外部 HTTP 请求），否则可能快速耗尽 worker 线程池；建议通过 @Blocking 显式标注（Quarkus 2.0+ 自动识别，但显式声明更清晰）；
- 若追求类似 C# async/await 的体验，Java 21+ 的虚拟线程（Project Loom）是更自然的替代方案——Quarkus 已原生支持（启用 -Dquarkus.virtual-threads.enabled=true），配合 Thread.ofVirtual().start() 或 CompletableFuture.supplyAsync(..., Thread.ofVirtual().factory())，可写出简洁、高并发的同步风格代码；
- 混合使用阻塞与响应式组件是安全的（如 quarkus-jdbc + quarkus-reactive-mysql-client 共存），Quarkus 会按各自线程模型正确调度。
总结：Quarkus 不强制响应式编程。选择阻塞 API 是受支持的一流实践——它不是妥协，而是权衡后的生产力优先设计。你无需为性能牺牲开发体验；真正的灵活性，在于让架构适配团队而非反之。
