不显式调用rollback()会导致数据库连接长期占用、连接池耗尽，甚至引发线程阻塞；所谓“资源”主要指JDBC连接、数据库锁及持久化上下文状态，而非仅内存缓存。
不显式调用rollback()会导致数据库连接长期占用、连接池耗尽，甚至引发线程阻塞；所谓“资源”主要指jdbc连接、数据库锁及持久化上下文状态，而非仅内存缓存。
在基于Hibernate的Java应用中，一个常见误区是认为：“既然数据库事务超时后会自动回滚，那在catch块里手动调用transaction.rollback()就是多此一举”。这种理解看似合理，实则忽略了事务生命周期与连接资源管理的关键机制。
一、事务 ≠ 仅内存中的Persistence Context
虽然Hibernate确实在一级缓存（Persistence Context）中暂存实体变更，但事务的起点和终点始终绑定于底层JDBC Connection。当你调用session.beginTransaction()时，Hibernate会：
- 从连接池获取一个物理JDBC连接（如HikariCP中的
HikariProxyConnection）； - 执行
connection.setAutoCommit(false)，开启数据库层面的事务； - 后续所有SQL（INSERT/UPDATE/DELETE）均通过该连接发送至数据库，并可能持有行锁、表锁等数据库资源。
这意味着：即使你未执行commit()，只要事务未结束（即未commit或rollback），该连接就处于“占用中”状态，且数据库仍维持事务快照与锁。
二、“超时自动回滚”不是兜底方案，而是故障表现
正如Stack Overflow所指出，若程序未主动结束事务，数据库或连接池确实可能在超时后强制终止——但这属于被动清理机制，存在严重隐患：
| 风险类型 | 具体表现 |
|---|---|
| 连接池枯竭 | 每个未关闭事务独占一个连接；若并发100请求均发生异常且未rollback，连接池（如默认大小20）迅速耗尽，后续请求将阻塞或抛出SQLException: Connection is not available
|
| 数据库锁堆积 | 未提交事务持有的行锁不会释放，可能导致其他事务长时间等待，甚至死锁（Deadlock） |
| 连接泄漏（Connection Leak） | 连接未归还池中，GC无法回收，最终触发连接池监控告警（如HikariCP的leakDetectionThreshold） |
✅ 正确实践：无论成功或失败，每个
beginTransaction()都必须有且仅有一次对应的commit()或rollback()
三、示例代码的优化：确保资源安全释放
你提供的代码已具备基本结构，但可进一步增强健壮性：
SessionFactory factory = new Configuration()
.configure("persistence.xml")
.addAnnotatedClass(Employee.class)
.buildSessionFactory();
Session session = null;
Transaction tx = null;
try {
session = factory.getCurrentSession();
tx = session.beginTransaction();
Employee person1 = session.get(Employee.class, 1L);
person1.setSalary(100000d);
if (true) {
throw new RuntimeException("error!");
}
tx.commit(); // ✅ 成功路径：明确提交
} catch (Exception e) {
e.printStackTrace();
// ✅ 异常路径：优先检查事务活性，再回滚
if (tx != null && tx.isActive()) {
try {
tx.rollback(); // ? 释放数据库连接与锁
} catch (RuntimeException rollbackEx) {
// 回滚本身可能失败（如网络中断），需记录但不可吞掉
log.error("Failed to rollback transaction", rollbackEx);
}
}
} finally {
// ✅ 确保Session关闭（避免一级缓存泄漏）
if (session != null && session.isOpen()) {
session.close();
}
}四、关键总结：三个“必须”
- 必须显式回滚：不是为了“重复数据库行为”，而是及时归还连接、释放锁、防止雪崩；
-
必须检查
tx.isActive()：避免对已结束事务重复操作导致IllegalStateException； - 必须在finally中关闭Session：防止Persistence Context长期驻留内存，造成内存泄漏与脏读风险。
简言之：rollback()不是“告诉数据库撤销数据”，而是“通知连接池：这个连接可以复用了”。在高并发系统中，这一行代码，往往就是服务稳定性与崩溃边缘的分水岭。
