应使用自定义IO线程池执行CompletableFuture.supplyAsync数据库查询，封装DAO调用并处理SQLException为RuntimeException，通过exceptionally/handle处理异常，避免事务上下文跨线程传递。
用 CompletableFuture.supplyAsync 执行耗时数据库查询，核心是把阻塞式 JDBC 操作（或 MyBatis/JPADao 调用）封装进异步任务，并确保线程安全和资源正确释放。
避免在默认 ForkJoinPool 中执行数据库操作
默认的 ForkJoinPool.commonPool() 适合 CPU 密集型任务，不适合 IO 阻塞操作。长时间阻塞会耗尽线程，拖慢整个应用。
- 显式传入自定义线程池，例如基于
ThreadPoolExecutor的 IO 专用池 - 推荐使用带名称、可监控、有拒绝策略的线程池，便于问题排查
- 示例：
Executors.newFixedThreadPool(10, new NamedThreadFactory("db-query-pool"))
把 DAO 查询逻辑包装成 Supplier
supplyAsync 接收一个 Supplier，需返回查询结果，不能直接抛出受检异常（如 SQLException），要转为运行时异常或显式处理。
- 不要在 lambda 内直接写
connection.createStatement().executeQuery(...)—— 连接获取、关闭必须可控 - 推荐复用已有 DAO 方法（如
userDao.findById(id)），该方法本身应是同步但线程安全的 - 若 DAO 方法可能抛出
SQLException，用 try-catch 包裹并转为RuntimeException（如new RuntimeException(e)）
正确处理异常与结果组合
异步查询失败不能静默吞掉异常，要通过 exceptionally、handle 或 whenComplete 显式响应。
-
exceptionally(e -> fallbackUser())：发生异常时返回兜底值 -
handle((result, ex) -> { if (ex != null) log.error("query failed", ex); return result; })：统一处理成功/失败 - 避免只调用
join()而不处理异常，否则调用线程会抛出CompletionException
注意连接与事务上下文不可跨线程传递
Spring 的 @Transactional 默认绑定当前线程，supplyAsync 切到新线程后事务上下文丢失，数据库连接也非原线程所持有。
- 不要在
supplyAsync内部调用被@Transactional修饰的方法（除非手动传播事务，但极不推荐） - 查询类操作通常无需事务，直接调用无事务注解的 DAO 即可
- 如果必须关联事务（如查完立刻更新），改用
TransactionTemplate在异步任务内显式开启新事务
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
