不显式回滚事务会导致数据库连接长期占用、连接池耗尽、锁资源滞留，甚至引发分布式事务挂起；“资源”不仅指数据库物理连接，还包括jdbc事务上下文、行级锁、undo log、一级缓存状态及连接池中的可用连接。
不显式回滚事务会导致数据库连接长期占用、连接池耗尽、锁资源滞留，甚至引发分布式事务挂起；“资源”不仅指数据库物理连接，还包括jdbc事务上下文、行级锁、undo log、一级缓存状态及连接池中的可用连接。
在Hibernate（或更广义的Java持久层）中，事务并非仅是内存中“逻辑标记”或一级缓存（Persistence Context）的简单开关——它背后紧密绑定着底层JDBC Connection与数据库服务端的真实事务生命周期。一旦调用session.beginTransaction()，Hibernate即通过JDBC驱动向数据库发起BEGIN TRANSACTION（或等效协议），数据库立即分配事务ID、开启undo log记录、加锁（如可重复读级别下的间隙锁/记录锁），并维持该事务上下文处于ACTIVE状态。
若仅抛出异常却不调用transaction.rollback()，将导致以下连锁问题：
? 连接池资源枯竭
连接未归还：虽然session.close()可能释放Session对象，但底层Connection仍被绑定在未终结的事务中，无法返回连接池。连接池（如HikariCP、Druid）会将其标记为“in-use”，直至超时（默认通常30秒–5分钟）。高并发下极易触发Connection acquisition timeout，整个应用请求阻塞。
? 数据库侧资源持续占用
- 行级锁不释放 → 其他事务对相同记录的UPDATE/DELETE被阻塞，引发级联等待甚至死锁；
- Undo log不断增长 → MySQL InnoDB中活跃事务越多，
ibdata1中回滚段占用空间越大，影响性能与恢复时间； - 事务视图（read view）长期存在 → 干扰MVCC机制，拖慢长事务快照生成，加剧
purge thread压力。
? Hibernate一级缓存与事务状态错位
即使变更尚未刷入数据库（flush未发生），Session内的一级缓存仍处于“脏”状态。若事务未明确回滚，后续同Session的查询可能返回不一致中间态数据；更严重的是，若该Session被复用（如getCurrentSession()在ThreadLocal中），残留的ACTIVE事务状态会使后续操作陷入不可预知行为（例如save()失败却无报错）。
✅ 正确实践：始终在catch块中显式回滚，并确保finally中安全清理
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
Session session = factory.getCurrentSession();
Transaction tx = null;
try {
tx = session.beginTransaction();
Employee emp = session.get(Employee.class, 1L);
emp.setSalary(100000.0);
if (true) {
throw new RuntimeException("Simulated business error");
}
tx.commit(); // 仅成功路径到达此处
} catch (Exception e) {
e.printStackTrace();
if (tx != null && tx.isActive()) {
try {
tx.rollback(); // ✅ 强制终止数据库事务，释放所有资源
} catch (RuntimeException rbEx) {
// rollback本身失败（如网络中断）属严重故障，需单独告警
log.error("Failed to rollback transaction", rbEx);
}
}
throw e; // 保持异常传播，避免静默吞掉错误
} finally {
// 注意：getCurrentSession() 通常由Spring或上下文管理，无需手动close；
// 若为openSession()，则此处应确保session.close()
}⚠️ 特别注意：
- 不要依赖“数据库自动超时回滚”作为兜底策略——那是容错边界，而非设计规范；
- Spring
@Transactional注解已自动封装commit/rollback逻辑，但仅适用于代理方法调用；若在同一个类内调用私有事务方法，或绕过代理直接执行，仍需手工管理； -
rollback-only状态（如UnexpectedRollbackException）往往源于子事务异常后父事务未感知，此时强制commit()将直接失败——这正凸显了显式状态控制的必要性。
简言之：rollback()不是可选的礼貌，而是对数据库、连接池、缓存与并发安全的契约式责任。每一次beginTransaction()，都必须对应一次确定性的commit()或rollback()，这是保障系统稳定性的底线工程。
