为含findById与save的方法添加@Transactional是否有实际意义？

先看你的代码：

void method() {
    SomeEntity entity = someJpaRepository.findById(...);
    // some simple logic
    someJpaRepository.save(entity);
}

不加@Transactional的实际行为 #

• Spring Data JPA的每个Repository方法默认都有独立的事务边界：findById是只读事务，save是读写事务。这意味着两次操作会分别从连接池获取、释放数据库连接，频繁的连接切换会产生额外开销，高并发场景下更明显。
• findById执行完毕后，事务结束，返回的实体会脱离Hibernate的持久化上下文（变成detached状态）。这时候调用save，Hibernate需要先合并这个实体、对比属性变化，再执行update语句——多了不必要的合并步骤。

加@Transactional的明确好处 #

• 复用数据库连接：整个方法在一个事务中执行，全程只用一个数据库连接，避免了两次连接获取/释放的开销，性能更优。
• 简化代码+优化持久化操作：在同一个事务里，findById返回的实体始终处于managed状态。你修改实体属性后，Hibernate会在事务提交前自动做脏检查（dirty check），把变更同步到数据库——这时候你甚至可以删掉save调用，代码更简洁。
• 事务原子性保障：就算现在逻辑简单，之后如果扩展（比如加关联实体操作、日志插入），整个方法的所有操作会作为一个原子单元，要么全部成功，要么全部回滚，避免出现数据不一致的情况。

关于Spring/Hibernate的自动优化 #

Spring和Hibernate不会自动把多个Repository方法的操作合并到一个事务，每个Repository方法的事务边界是独立的。Hibernate的优化只在单个事务内部生效，跨事务的操作它帮不上忙。

总结 #

如果这个方法会被频繁调用，或者未来有扩展可能，加@Transactional绝对有意义——既提升性能，又保证数据一致性，还能简化代码。就算是偶尔调用的简单方法，加了也没坏处，反而更符合Spring Data JPA的规范。

内容的提问来源于stack exchange，提问作者Kirill Zhurbin