避免长事务导致连接池耗尽，核心是控制事务边界、缩短持有连接时间并确保及时归还；需显式缩小@transactional范围、移出非db操作、分批处理、分段提交+补偿、配置超时与连接池参数、杜绝资源泄漏。
避免长事务导致连接池耗尽，核心是控制事务边界、缩短持有连接的时间，并确保连接及时归还。这不是靠加连接数硬扛，而是从设计和编码习惯入手。
明确事务边界，只包裹真正需要原子性的操作
@Transactional 默认作用于整个方法，容易把耗时操作（如远程调用、文件读写、复杂计算）也裹进去，导致连接被占用过久。应手动缩小事务范围：
- 用 @Transactional(propagation = Propagation.REQUIRED) 显式标注最小必要逻辑块，比如仅包裹 insert/update/delete 操作本身
- 把非数据库操作（如 HTTP 调用、日志记录、消息发送）移出事务方法，或改用事件机制异步处理
- 避免在事务方法内做循环批量插入——改用批处理（JdbcTemplate.batchUpdate）或分批次提交
主动拆分大事务，用业务补偿替代单一大事务
涉及多表、多步骤的业务（如订单创建+库存扣减+积分更新），不应强求在一个事务里完成。可采用“分段提交 + 补偿机制”：
Java Linux版
下载
Java Linux版下载入口，提供 Oracle JDK 26.0.2 官方 Linux 安装包、Java 环境配置、JDBC 数据库连接和 Java 服务端开发相关信息。
- 每一步独立事务：订单落库 → 库存扣减 → 积分变更，各自 commit
- 失败时触发补偿：例如库存扣减失败，就回滚已生成的订单（或标记为异常待人工介入）
- 借助消息队列解耦后续步骤，避免事务跨服务延长持有时间
监控与兜底：配置超时 + 实时感知连接状态
再好的设计也需要防御性配置：
- 给 @Transactional 加 timeout = 30（单位秒），超时自动 rollback，防止死锁或卡顿拖垮连接池
- HikariCP 配置 connection-timeout: 30000（30秒）和 max-lifetime: 1800000（30分钟），避免获取不到连接或使用陈旧连接
- 暴露 HikariCP 的 MBean，定期检查 activeConnections / totalConnections 比值，超过 80% 就预警
杜绝连接泄漏，确保每次获取都对应释放
即使用了连接池，未关闭 ResultSet/Statement 或未正确 try-with-resources，仍可能让连接无法回收：
- 所有 JDBC 操作必须用 try-with-resources，保证 Connection/Statement/ResultSet 自动 close
- Spring 中优先使用 JdbcTemplate 或 MyBatis，它们内部已封装资源管理；避免手写 DriverManager.getConnection()
- 禁用 autocommit = false 后忘记 commit/rollback —— 可通过 AOP 切面统一拦截未结束事务并告警
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
