一个方法是否需要添加 @Transactional 注解？直接给出结论：问题的核心并非“要不要”，而是“这个方法是否定义了一个业务原子操作”。
一、什么情况下必须使用事务？
记住一个核心原则就足够了：当一个方法内部的操作必须满足“要么全部成功，要么全部失败”的一致性要求时，就必须使用事务。
这是一个典型的应用场景：
@Transactional
public void createOrder() {
orderMapper.insert(order);
stockMapper.reduce(stock);
}
这个方法中包含了两个关键操作：
- 创建订单
- 扣减库存
只要其中任意一步执行失败，为了保证业务数据的一致性，另一步操作也必须被回滚。这正是事务存在的根本意义。
二、什么情况下不应添加事务？
1. 纯查询方法
public User getById(Long id) {
return userMapper.selectById(id);
}
对于只涉及数据读取的查询操作，不存在数据一致性问题。为其添加事务注解只会徒增数据库连接开销与性能损耗，属于画蛇添足。
2. 单条写操作
public void updateName(Long id, String name) {
userMapper.updateName(id, name);
}
如果方法中只包含单条数据更新或插入的 SQL 语句：
这种情况下，事务机制并没有额外价值，@Transactional 注解显得多余。
3. 非核心辅助流程
某些操作属于业务主流程之外的辅助性功能，例如：
这些操作的失败，不应影响核心业务逻辑的正常进行。因此，它们不应该与核心业务操作绑定在同一个数据库事务中，通常可以采用异步等方式处理。
三、最容易被忽略的三个陷阱
1. 捕获异常却未抛出
@Transactional
public void save() {
try {
// ... 数据库操作
} catch (Exception e) {
log.error("error", e); // 仅记录日志，未抛出异常
}
}
这样做只有一个后果：事务不会回滚。 @Transactional 默认在遇到运行时异常和 Error 时才回滚。如果异常在方法内部被“吞掉”，事务管理器将无法感知到错误，从而导致错误的数据被提交。
2. 类内部方法调用
public void A() {
B(); // 内部调用，事务失效
}
@Transactional
public void B() {
// 数据库操作
}
此时 B() 方法上的事务注解不会生效。因为基于代理的 Spring 事务管理机制，只有通过代理对象调用的方法才会被增强。这种直接的内部调用绕过了代理，事务拦截器没有机会介入。
3. 将事务视为“万能保险”
抱着“加上总没坏处”的想法滥用 @Transactional 是错误的。每个事务都会：
- 占用数据库连接资源。
- 可能延长数据锁的持有时间。
- 在高并发场景下影响系统吞吐量。
随意添加事务注解，是系统性能问题的潜在导火索。
总结一下：@Transactional 注解描述的是业务逻辑的边界，而非一种可以随意使用的编码习惯。正确理解并使用它，是每一位Spring Boot开发者必备的技能。如果你想深入探讨更多技术细节，欢迎到 云栈社区 的Java板块与其他开发者交流。
发表于 4 天前
|
查看: 16|
回复: 0
