Java中try-catch-finally不能直接控制事务回滚，真正起作用的是事务管理器；Spring默认仅对RuntimeException和Error自动回滚，受检异常需显式配置rollbackFor或包装为运行时异常。
在 Java 中，try-catch-finally 本身**不能直接控制事务回滚**，它只是异常处理机制；真正决定事务是否回滚的是事务管理器（如 Spring 的 @Transactional）以及你如何配合异常类型和手动操作。关键在于：让事务感知到“出错了”，并按预期终止。
明确事务回滚的触发条件
Spring 默认只对 未检查异常（RuntimeException 及其子类）和 Error 自动回滚；对受检异常（比如 IOException、SQLException）默认不回滚。如果你在 try 块里捕获了异常但没重新抛出，或者抛出的是受检异常，事务很可能就“悄悄提交”了。
- ✅ 正确做法：不捕获会破坏业务一致性的异常，或捕获后重新抛出 RuntimeException
- ❌ 错误做法：在
catch里吞掉异常、记录日志后继续执行，却没做任何回滚指示 - ⚠️ 注意：
finally块中不要执行可能改变数据状态的操作（如 insert/update），它只适合释放资源（如关闭连接、清理线程变量）
用 throw new RuntimeException 包装受检异常
当业务逻辑抛出受检异常（如调用外部服务失败），又希望事务回滚时，可在 catch 中包装为运行时异常再抛出：
try {
orderService.createOrder(order);
paymentService.pay(order);
} catch (PaymentException e) {
// 支付失败 → 需要回滚整个事务
throw new RuntimeException("支付失败，事务将回滚", e);
}
这样 Spring 就能识别并触发回滚。也可以用 @Transactional(rollbackFor = PaymentException.class) 显式声明，效果等价。
立即学习“Java免费学习笔记（深入）”；
必要时手动设置回滚（setRollbackOnly）
在某些底层场景（如使用 JTA 或原生 JDBC + DataSourceTransactionManager），若无法靠抛异常驱动回滚，可手动标记：
- 在 Spring 环境中，注入
TransactionStatus或通过TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() - 示例：不推荐日常使用，仅用于复杂分支逻辑中需“静默回滚”
try {
doSomething();
if (shouldNotCommit()) {
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
return;
}
} catch (Exception e) {
throw new RuntimeException(e);
}
finally 中只做安全清理，绝不干扰事务状态
finally 是为了兜底，不是为了“挽救事务”。常见安全操作包括：
- 关闭数据库连接（如果没用连接池）、输入流、HTTP 客户端
- 清除 ThreadLocal 变量（尤其在异步或线程复用场景下）
- 释放分布式锁（如 RedisLock），但要确保释放逻辑本身不抛异常，否则可能掩盖原始错误
避免在 finally 里调用 service 方法、更新数据库、发送 MQ 消息——这些操作不在当前事务上下文中，容易引发不可预知行为。
