在 quarkus 中，即使不启用任何响应式扩展（如 `quarkus-reactive-postgresql-client`），应用默认仍以阻塞方式执行 i/o 操作；此时 quarkus 会自动将阻塞调用调度到专用工作线程池，保障主线程（如 netty 事件循环）不被阻塞。
Quarkus 的核心设计理念是“响应式内核，阻塞友好”。这意味着其底层运行时（基于 Vert.x 和 Netty）采用非阻塞事件驱动模型，但并不强制开发者编写响应式代码。当你使用传统阻塞 API（例如 JDBC、RestTemplate、FileInputStream 或 Spring Data JPA），Quarkus 会智能识别这些调用，并自动将其移交至内置的 worker thread pool（默认为 executor 类型的 ManagedExecutor）中执行，从而避免阻塞 IO 线程（如 HTTP 请求处理线程）。
例如，以下是一个典型的阻塞式 REST 端点：
@Path("/api/users")
public class UserResource {
@GET
@Produces(MediaType.APPLICATION_JSON)
public List<User> listUsers() {
// 假设这是 JDBC 阻塞查询
return userRepository.findAll(); // 同步、阻塞调用
}
}尽管 findAll() 内部可能触发数据库 I/O，Quarkus 仍能保证该请求不会拖垮整个 HTTP 处理器——它会在后台线程完成查询后，再将结果返回给事件循环并写回响应。
⚠️ 注意事项：
- 性能权衡：阻塞调用虽开发简单，但在高并发、低延迟场景下，线程上下文切换与线程池争用可能成为瓶颈；而原生响应式客户端（如 reactive-pg-client）可实现真正的单线程高吞吐。
- 线程安全：在阻塞模式下，业务逻辑仍运行于 worker 线程，因此需确保共享资源（如静态变量、缓存）的线程安全性。
- 无 async/await 等价物：Java 当前（截至 JDK 21+）尚未提供语言级 async/await（Project Loom 的虚拟线程是另一条路径），但 Quarkus 对虚拟线程（quarkus-virtual-threads）已提供原生支持——你可启用 @Blocking + Thread.ofVirtual().start() 实现类 async/await 的简洁异步风格，且无需改写现有阻塞逻辑。
✅ 总结：你可以完全避开 Project Reactor 或 Mutiny 编程模型，坚持熟悉的同步编码习惯；Quarkus 的运行时会为你兜底处理线程调度——这正是它“开发者优先”哲学的关键体现。如未来需要极致伸缩性，再渐进式引入响应式客户端或虚拟线程即可。
