关键不是加资源，而是切断阻塞传播链：禁用同步jdbc裸奔，改用r2dbc或异步封装；为db操作单独配小线程池；hikaricp开启泄漏检测与3秒连接超时；sql、事务、连接均需显式超时控制并独立生命周期。
避免并发流处理中线程死卡拖垮连接池，关键不是“加资源”，而是切断阻塞传播链——让数据库连接不被卡死的线程长期占用，同时确保线程自身不会陷入不可退出状态。
堵住源头：禁止同步 JDBC 在虚拟线程或高并发流中裸奔
Java 传统 JDBC 是同步阻塞 IO，一旦调用 executeQuery() 或 update()，当前线程（哪怕是虚拟线程）会全程挂起，无法释放载体线程。若此时连接池已满，新请求就会在获取连接阶段排队；而正在执行的请求又霸占着连接和载体线程，形成双重锁死。
- Spring Boot 3.4+ 启用虚拟线程时，务必禁用
JdbcTemplate和 MyBatis 同步模式，改用 R2DBC（如r2dbc-postgresql）或带异步封装的客户端 - 若必须用 JDBC，至少将数据库操作移出流式处理主线程：用
CompletableFuture.supplyAsync(..., dbExecutor)拆离，并为dbExecutor单独配小而稳的线程池（如 core=4、max=8、队列有界） - HikariCP 必须开启
leakDetectionThreshold=60000，否则连接泄漏会静默吃光池子，直到某次突发流量才集中爆发
收紧边界：给每个数据库操作套上“超时熔断”
没有超时的数据库调用，等于给线程池埋定时炸弹。一个慢查询卡住 30 秒，就可能让 10 个并发流全部堵死。
- 在 HikariCP 配置中设
connection-timeout=3000（3 秒内拿不到连接就失败），避免无限等待 - SQL 层面加
SET STATEMENT max_execution_time = 2000 FOR ...（MySQL 5.7+），或在 MyBatis 的<select timeout="2"> 中声明秒级超时</select> - 事务内所有操作必须显式控制耗时：Spring
@Transactional(timeout = 3)，防止 autocommit=false 下事务空悬
切断传播：流式处理不共享连接，也不跨阶段持有连接
常见错误是用一个 Connection 对象贯穿 map/filter/flatMap 全流程，或者在 parallelStream 中复用同一个 DataSource 获取的连接——这极易引发连接未关闭、事务交叉、或连接被不同线程并发操作而抛异常。
- 每个数据库操作应独立获取连接、执行、关闭：优先使用 try-with-resources，或确保
flatMap内部完成整个 DB 生命周期 - 避免在
parallelStream中直接调用 DAO 方法；改用stream().map(item -> CompletableFuture.supplyAsync(() -> dao.get(item), dbPool))显式隔离 - 不要把 Connection、PreparedStatement 等对象作为 lambda 外部变量捕获；它们不是线程安全的，且生命周期极难追踪
对齐超时：MySQL 服务端参数必须和连接池联动
即使应用侧设了 3 秒超时，若 MySQL 自己把空闲连接在 2 秒后主动断开（wait_timeout=2），HikariCP 取出的连接就会报 Communications link failure，触发重试逻辑，进一步加剧连接争抢。
- MySQL 中设
wait_timeout = 630（10 分 30 秒），比 HikariCP 的idleTimeout=600000（10 分钟）多留 30 秒缓冲 - 禁用
autoReconnect=true（JDBC URL 中），它已被弃用且不可靠；改用 HikariCP 自带的连接验证机制（connection-test-query=SELECT 1） - 定期查
SHOW PROCESSLIST，过滤Command='Sleep' AND Time > 30的连接，定位哪类业务代码释放不及时
