防范长事务需从设计与监控双管齐下：明确事务边界、剥离耗时操作、配置多层超时，并建立常态化排查机制。
防范长事务引发的连接池耗尽和性能劣化，核心是控制事务边界、缩短连接持有时间、提前暴露问题。不是等报错再救火，而是从设计和监控两个层面主动设防。
明确事务边界，避免“大包大揽”
声明式事务（@Transactional）默认以整个方法为边界——方法不返回，连接就不释放。常见踩坑点包括：
- 在事务方法里调用远程接口（如 HTTP、Feign），对方响应慢或超时，连接被锁住几十秒甚至几分钟
- 事务内解析超大 Excel/JSON、压缩解压、密集循环计算等纯 CPU 操作
- 把日志记录、消息通知、缓存刷新等非数据一致性操作也塞进事务里
- 误用编程式事务（TransactionTemplate），忘记 commit/rollback 或异常后提前 return
拆分事务逻辑，让连接尽早归还
对确实需要耗时操作的业务，必须剥离事务上下文：
- 读写分离：查询类操作尽量用只读事务（@Transactional(readOnly = true)），部分数据库驱动可复用连接或走连接池优化路径
- 两阶段提交思路：先完成数据库变更并提交，再异步处理后续动作（如发 MQ、调外部服务），失败走补偿而非回滚
- 手动控制粒度：用 @Transactional(propagation = Propagation.REQUIRES_NEW) 隔离关键子流程，避免主事务被拖长
- 对必须同步等待的场景，考虑加超时熔断（如 TimeoutUtils 包裹调用，超时抛 RuntimeException 触发自动回滚）
配置多层超时与连接池可观测性
单靠代码自律不够，需靠配置兜底和监控预警：
- HikariCP 层：设置 connection-timeout（如 30s）、idle-timeout（如 10 分钟）、max-lifetime（如 30 分钟），防止连接僵死
- Spring 事务层：统一配置 @Transactional(timeout = 10)，或在 XML/JavaConfig 中设全局默认超时（transaction-manager 的 defaultTimeout）
- 数据库层：MySQL 调整 innodb_lock_wait_timeout（建议 10–30s）、wait_timeout（避免 Sleep 连接堆积）
- 开启 DEBUG 日志：启用 logging.level.com.zaxxer.hikari=DEBUG 和 logging.level.org.springframework.transaction=TRACE，观察连接获取/归还时间差是否等于业务耗时
建立常态化排查机制
不能只靠故障驱动，日常就要盯住几个关键信号：
- 定期查 INFORMATION_SCHEMA.INNODB_TRX，筛选 trx_state = 'RUNNING' 且持续超 5 秒的事务
- 监控 HikariCP 的 active、pending、idle 实时指标，设置告警阈值（如 active ≥ 90% maxPoolSize）
- 结合 jstack 抓取线程快照，搜索 @Transactional 方法名 + RUNNABLE 状态，确认是否真在执行耗时逻辑
- 对高频事务接口做压测，对比开启/关闭事务时的连接池占用曲线和 P99 延迟变化
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
