“只要你不考虑事务的问题，总有一天事务会来考虑你。”
这句话在最近的一次 code review 中，让我体会到了它的分量。当我看到同事在一个复杂的业务逻辑中混用了 @Transactional 注解和 TransactionTemplate 时，就预感到可能会有隐患。我问他为什么这样设计，他的回答是：“反正都能实现事务，应该没什么区别吧？”
这个回答让我意识到，许多开发者对 Spring 的事务管理机制理解得可能并不深入。我们通常知道加个 @Transactional 就能开启事务，但对于何时该用声明式、何时该用编程式，以及它们背后的工作原理，却很少深究。
事务管理看似简单，实则暗藏玄机。今天我们就来深入聊聊 Spring 中的三种事务管理方式，以及它们各自的适用场景和潜在的风险。
01 三种方式，各有千秋
Spring 给我们提供了三种处理事务的方式：@Transactional 注解、TransactionTemplate 和直接使用 TransactionManager。它们就像三种不同的工具，各有各的适用场景。
@Transactional：最省心的方式
提到事务管理，基本上都会首先想到 @Transactional。确实，它用起来简单直接，在方法上加一个注解就完事了。
@Service
public class UserService {
@Transactional
public void createUser(User user) {
userRepository.save(user);
// 如果这里抛异常，上面的操作会回滚
sendWelcomeEmail(user);
}
}
它最大的优点是 无侵入性。业务代码保持干净，事务逻辑完全交给 Spring 在背后处理。然而，这种“黑盒式”的便利是有代价的。Spring 通过 AOP 来实现声明式事务，为方法包裹了一层代理，这会带来几个让人头疼的典型问题：
- 内部方法调用失效：这是最容易踩的坑！当同一个类内部的方法调用带有
@Transactional 注解的方法时，事务不会生效，因为内部调用不会经过代理。
- 只对 public 方法生效：在私有或 protected 方法上添加
@Transactional 是无效的。
- 需要匹配异常类型：默认情况下，只有
RuntimeException 和 Error 会触发回滚，检查型异常（Checked Exception）需要额外配置。
我们来看一个内部调用失效的例子：
@Service
public class UserService {
public void batchCreate(List<User> users) {
for (User user : users) {
createUser(user); // ❌ 这里事务不会生效！
}
}
@Transactional
public void createUser(User user) {
userRepository.save(user);
}
}
虽然这些都是老生常谈的问题，但在实际开发中，因为此类细节导致的 Bug 依然屡见不鲜。
TransactionTemplate：可控性更强的选择
TransactionTemplate 可以看作声明式事务和底层编程式事务之间的一个平衡点。它既保持了一定的灵活性，又不会让代码变得过于复杂。
@Service
public class UserImportService {
@Autowired
private TransactionTemplate transactionTemplate;
public void importUsers(List<User> users) {
for (User user : users) {
try {
transactionTemplate.execute(status -> {
userRepository.save(user);
userProfileRepository.save(user.getProfile());
return null;
});
} catch (Exception e) {
log.error("导入用户失败: {}", user.getUsername(), e);
}
}
}
}
使用 TransactionTemplate 的好处是你可以精确控制事务的边界，且无需担心内部方法调用的问题。你甚至可以在事务执行过程中获取到 TransactionStatus 对象，进行更细致的控制，例如根据业务条件决定是否回滚：
@Service
public class AccountService {
@Autowired
private TransactionTemplate transactionTemplate;
public void transfer(String fromAccount, String toAccount, BigDecimal amount) {
transactionTemplate.execute(status -> {
try {
accountRepository.debit(fromAccount, amount);
accountRepository.credit(toAccount, amount);
return null;
} catch (InsufficientFundsException e) {
// 可以根据业务逻辑手动标记回滚
status.setRollbackOnly();
throw e;
}
});
}
}
当然，这种方式也有缺点。最明显的是代码可读性会略微下降，因为业务逻辑和事务管理逻辑会交织在一起。如果业务逻辑本身就很复杂，嵌套层次过深，代码的维护性也会变差。
TransactionManager：最灵活（也最易错）的方式
如果你需要完全的控制权，那就得直接使用 PlatformTransactionManager 了。这种方式最灵活，但灵活的代价就是容易出错。
@Service
public class PaymentService {
@Autowired
private PlatformTransactionManager transactionManager;
public void processPayment(Payment payment) {
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
TransactionStatus status = transactionManager.getTransaction(def);
try {
paymentRepository.save(payment);
notificationService.sendPaymentConfirmation(payment);
transactionManager.commit(status);
} catch (Exception e) {
transactionManager.rollback(status);
throw e;
}
}
}
这种方式的好处是可以精确控制事务的每一个细节，比如隔离级别、传播行为、超时时间等。但是代码量会显著增加，而且极易出错——一旦忘记提交或者回滚，就会导致数据不一致的“惊喜”。
02 实战中该如何选择？
经过上面的对比，到底该怎么选择呢？我的建议是这样的：
- 大部分情况下，
@Transactional 就够用了。它简单、直接，能解决 90% 的常见场景。除非你遇到了它无法解决的问题，否则没必要把事情复杂化。
- 需要精细控制时，考虑
TransactionTemplate。比如你需要在事务执行过程中根据某些条件决定是否回滚，或者需要在一个方法里灵活管理多个独立的事务边界，这时候 TransactionTemplate 就更合适。
- 极少数情况下才直接用
TransactionManager。通常是在编写底层框架代码，或者有非常特殊、定制化的事务需求时才会用到。
03 一个具体的例子
让我们通过一个实际的例子来感受三种方式的差异。假设我们要实现一个批量导入用户的功能，要求是：如果某个用户导入失败，不应该影响其他用户的导入。
如果只用 @Transactional，可能会这样写：
@Service
public class UserImportService {
public void importUsers(List<User> users) {
for (User user : users) {
try {
createUserWithTransaction(user); // 注意，这样写事务不会生效！
} catch (Exception e) {
log.error("导入用户失败: {}", user.getUsername(), e);
}
}
}
@Transactional
public void createUserWithTransaction(User user) {
userRepository.save(user);
userProfileRepository.save(user.getProfile());
}
}
⚠️ 上面的代码中，事务是不会生效的！ 这是因为 importUsers 方法调用同一个类中的 createUserWithTransaction 方法，属于 内部方法调用。Spring AOP 通过代理实现事务，而同一个类内部的方法调用不会经过代理，所以 @Transactional 注解完全失效。
常见的解法是将有事务的方法抽取到另一个 Service 中：
@Service
public class UserImportService {
@Autowired
private UserTransactionService userTransactionService;
public void importUsers(List<User> users) {
for (User user : users) {
try {
userTransactionService.createUserWithTransaction(user); // ✅ 这样才会生效
} catch (Exception e) {
log.error("导入用户失败: {}", user.getUsername(), e);
}
}
}
}
@Service
public class UserTransactionService {
@Transactional
public void createUserWithTransaction(User user) {
userRepository.save(user);
userProfileRepository.save(user.getProfile());
}
}
这种方式的问题是需要额外创建一个 Service 类，增加了代码的复杂度。当然，也可以使用 AopContext.currentProxy() 或通过 ApplicationContext 获取代理对象来调用，但始终让人觉得不够优雅。
这也是为什么在这种场景下，TransactionTemplate 往往是更好的选择。 使用方式正如前文示例所示，事务边界在代码中一目了然，且完全避免了代理调用问题。至于 TransactionManager，在常规业务开发中基本不会用到。
04 那些年踩过的坑
在事务管理的路上，我也踩过不少坑。印象最深的一次是在处理一个报表统计功能时，由于数据量巨大，我想着用只读事务来提升性能：
@Transactional(readOnly = true)
public List<ReportData> generateReport(ReportQuery query) {
// 复杂的查询逻辑
return reportRepository.findComplexData(query);
}
结果发现性能提升并不明显。后来才知道，只读事务的效果高度依赖于数据库驱动和连接池的具体配置，在某些配置下收益甚微。
另一个常见问题是事务超时。有些开发者喜欢把超时时间设置得很长，生怕业务逻辑执行慢导致事务回滚：
// 这样设置风险很高，不推荐，除非你明确知道自己在做什么
@Transactional(timeout = 300) // 5分钟超时
public void processLargeDataSet(List<Data> dataList) {
// 大量数据处理逻辑
}
这样做风险很明显：如果真出现了死锁或慢查询，相关数据库连接会被长时间占用，可能导致系统整体无响应。更好的做法是把大事务拆分成多个小事务，或者改写成批处理模式。
05 谨慎混合使用
回到文章开头提到的情况，在同一个 Service 或方法中混合使用不同的事务管理方式，很容易出问题。最常见的是对事务传播行为的理解出现偏差。
@Service
public class OrderService {
@Autowired
private TransactionTemplate transactionTemplate;
@Transactional
public void processOrder(Order order) {
orderRepository.save(order);
// 这里又用了一个事务模板，其传播行为可能与外层@Transactional事务产生复杂的交互，不易理解
transactionTemplate.execute(status -> {
auditRepository.save(new OrderAudit(order));
return null;
});
}
}
这种混用的代码会让事务边界变得模糊，难以理解，调试起来也非常麻烦。因此，强烈建议在一个 Service 类中尽量保持事务管理方式的一致性，除非有非常充分的理由，否则不要轻易混用。
06 总结
最后我们来总结一下。对于刚接触 Spring 事务管理的开发者，建议先把 @Transactional 的各种特性、局限和常见“坑点”搞清楚，它足以应对大部分常规场景。当你真正需要更精细的控制时，再去考虑 TransactionTemplate。
对于有经验的 Java 开发者，在已经熟练掌握编程式事务控制的前提下，可以多关注事务对系统性能的影响。记住，事务不是万金油，不当使用反而会带来性能瓶颈。
最重要的是，无论选择哪种方式，都要保证代码的可读性和可维护性。技术是为业务服务的，而代码是需要团队共同维护的资产，不要为了炫技而让代码变得晦涩难懂。
希望这篇文章能帮你理清这三种方式的区别与选型思路。毕竟，在数据一致性面前，再小心都不为过。
本文技术讨论欢迎在云栈社区与其他开发者继续交流。
发表于 3 天前
|
查看: 15|
回复: 0
