## 01、痛点

凌晨两点，运维群弹告警：订单服务数据库连接池耗尽，接口平均响应从 80 毫秒飙到 4 秒，大量下单请求超时。排查发现，一位开发在创建订单的事务里加了一次外部库存预占调用，对端系统抖动，事务一直不提交，连接和锁全部卡住。类似的问题还有很多：有人给方法加上 @Transactional，结果同类方法里内部调用，注解根本不生效；有人把整条下单链路包成一个事务，包含 HTTP、消息、通知，最后锁等待和死锁频发；还有人遇到受检异常不回滚，怀疑框架有问题。

我是老李。今天我们不讲“注解怎么加”，而讲 @Transactional 真正在表达什么。它不是一个“加上就安全”的开关，而是一段业务一致性边界。这个问题现在特别值得讲，因为系统越来越分布式、并发越来越高，事务边界一旦画错，破坏面会比想象中大得多。

## 02、是什么

@Transactional 是 Spring 提供的事务管理注解。很多人的理解停留在“加上它，方法里的数据库操作就会自动回滚”。这句话只说对了一半。更准确的说法是：@Transactional 声明了一个事务边界，告诉 Spring 从代理方法进入开始，到方法结束，内部涉及的数据库写操作要纳入同一个数据库事务；如果发生符合回滚规则的异常，事务管理器执行 rollback；否则统一 commit。

这个边界包含两层含义。第一层是 Spring 事务管理，负责根据传播行为、隔离级别、回滚规则来决定事务的开启、加入、挂起、提交和回滚。第二层是数据库事务，通常由 MySQL InnoDB 保证 ACID。Spring 只是把连接绑定到当前线程，并在合适的时机调用 commit 或 rollback，真正的原子性、隔离性和持久性仍然由 InnoDB 的 undo log、redo log、锁和 MVCC 完成。

所以，注解本身不是安全符，它只是你向系统发出的一个声明：这段代码里的数据库状态变更必须一起成功，或者一起失败。边界划得对不对，取决于业务，而不仅仅取决于注解。

## 03、为什么

过去单体应用代码简单，一个 Service 方法常常就是一个完整业务动作，事务边界天然清晰。现在系统拆成多个服务，下单可能涉及订单、库存、支付、风控、通知，外部调用多，数据库并发高。此时事务边界不再显而易见，很容易出现两种偏差：一是事务包得太大，把不该包含的外部 HTTP、消息、通知都圈进来；二是事务边界划得太碎，本应同时成功的操作被拆开，导致一部分成功、一部分失败。

更关键的是，只停留在注解层无法解释常见问题。比如为什么同类内部调用会失效？为什么 REQUIRES_NEW 能让内层事务独立提交？为什么可重复读级别下仍然可能看到幻读？这些都需要向下理解 Spring AOP Proxy、事务传播、隔离级别，以及 MySQL InnoDB 的锁和 MVCC。把上层和下层串起来，才能真正知道边界应该落在哪里。

## 04、架构

先看 Spring AOP Proxy。@Transactional 本质上依赖代理对象生效。当外部调用一个被代理的事务方法时，调用会先经过代理拦截器，拦截器根据事务属性向事务管理器申请事务，再调用目标方法。JDK 动态代理或 CGLIB 生成的代理对象只负责拦截外部调用；如果目标方法内部直接调用同类另一个带注解的方法，这个调用不经过代理，注解自然不生效。

传播行为决定事务如何流转，常见的有几种。REQUIRED 是默认值：当前有事务就加入，没有就新建，适合大多数场景。REQUIRES_NEW 会挂起当前事务，新建一个独立事务，内层事务提交或回滚不影响外层，适合需要独立记录的旁路场景。NESTED 使用保存点机制，内层回滚可以回滚到保存点，不会影响外层已执行的操作，但不是所有数据库都支持。其他如 MANDATORY、SUPPORTS、NOT_SUPPORTED、NEVER 则分别用于强制要求或禁止事务。

隔离级别决定多个事务之间的可见性。READ_UNCOMMITTED 可能读到未提交数据，出现脏读；READ_COMMITTED 解决脏读，但不可重复读和幻读仍在；REPEATABLE_READ 是 InnoDB 默认级别，通过 MVCC 解决不可重复读，并通过间隙锁部分解决幻读；SERIALIZABLE 最严格，基本串行执行，性能较差。

回滚规则经常被误解。默认只对 RuntimeException 和 Error 回滚，对受检异常不回滚。如果方法里抛出 IOException 之类受检异常，而又没有通过 rollbackFor 指定，事务会照常提交，这就是“明明抛异常却还是写进去了”的原因。readOnly 则更多是提示和优化，它不会强制阻止写入，但 Hibernate 等框架可能在只读事务中关闭自动 flush 行为，减少开销。Flush 与 commit 不是一回事，flush 只是把持久化上下文中的 SQL 同步到数据库，真正提交仍然由 commit 完成，未提交数据对其他事务的可见性由隔离级别决定。

再往下看 MySQL InnoDB。ACID 中，原子性靠 undo log 回滚，持久性靠 redo log 保证，隔离性靠锁和 MVCC，一致性则是综合结果，既依赖约束，也依赖业务。MVCC 通过隐藏列和 undo 版本链保存多版本数据，普通快照读生成 ReadView 判断哪些版本可见，因此读不阻塞写。当前读如 UPDATE、DELETE 或 SELECT FOR UPDATE 则需要加锁。可重复读级别下，快照读在事务内首次读取时建立 ReadView，此后读到的版本基本稳定；当前读则还要配合间隙锁和临键锁来防止幻读。理解这些后，就会明白为什么事务越大、锁持有越久，越容易撞出锁等待和死锁。

## 05、实战

用一个订单创建场景来验证。假设有三张表：订单主表、库存表、支付记录表。目标流程是“创建订单 → 扣库存 → 创建支付记录”。我们在 Spring Boot 项目中定义两个独立 Bean：InventoryService 负责扣库存，PaymentService 负责创建支付记录；OrderService 注入它们，并声明事务。

```java
@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private InventoryService inventoryService;
    @Autowired
    private PaymentService paymentService;

    @Transactional(rollbackFor = Exception.class)
    public void createOrder(OrderCreateRequest request) {
        Order order = new Order();
        order.setOrderNo(request.getOrderNo());
        orderMapper.insert(order);

        inventoryService.deduct(request.getSku(), request.getQuantity());

        paymentService.createPayment(request.getOrderNo(), request.getAmount());

        if (request.isMockFail()) {
            throw new RuntimeException();
        }
    }
}
```

外部通过 Spring 代理调用 createOrder 时，三个写操作处于同一个事务。故意把 mockFail 设置为 true，方法执行到支付记录创建后抛出 RuntimeException，事务回滚。最终订单主表、库存表、支付记录表都不会新增数据。这就是事务边界正确时的表现：要么一起成功，要么一起失败。

接下来演示内部调用失效。如果在 OrderService 里新增一个普通方法，直接调用同类带注解的方法：

```java
public void createOrderDirect(OrderCreateRequest request) {
    this.createOrderInternal(request);
}

@Transactional(rollbackFor = Exception.class)
public void createOrderInternal(OrderCreateRequest request) {
    orderMapper.insert(order);
    inventoryService.deduct(request.getSku(), request.getQuantity());
    paymentService.createPayment(request.getOrderNo(), request.getAmount());

    if (request.isMockFail()) {
        throw new RuntimeException();
    }
}
```

此时外部调用 createOrderDirect，它又内部调用 createOrderInternal。由于 this 调用不经过 Spring 代理，@Transactional 不会生效。方法抛异常后，三张表的数据不会回滚，订单、库存、支付记录可能已经落库，业务出现部分成功。解决办法不是继续加注解，而是把事务方法放到独立 Bean，让外部调用经过代理；或者从业务设计上重新梳理边界，避免同类内部调用依赖注解。

再看外部 HTTP 调用的问题。假设在事务中插入订单后调用外部价格接口：

```java
@Transactional
public void createOrderWithRemoteCall(OrderCreateRequest request) {
    orderMapper.insert(order);
    remoteClient.queryPrice(request);
    paymentService.createPayment(request.getOrderNo(), request.getAmount());
}
```

如果 queryPrice 正常但很慢，一次调用 2 秒，事务会持有一个数据库连接和已经产生的行锁 2 秒。并发一高，连接池很快耗尽，其他请求得不到连接，锁等待也会堆积。即使外部调用最终成功，数据库资源已经被白白占用。更合理的做法是把 queryPrice 放到事务边界之外，先拿到价格，再进入事务处理本地写操作。

## 06、洞见

事务范围为什么不是越大越安全？因为事务的核心代价是锁和连接。范围越大，锁持有时间越长，隔离范围扩大，冲突概率上升。一个事务里如果既有耗时外部调用，又有多个表的写操作，等于把所有资源都压在一条长链路上。并发场景下，这会让多个事务互相等待，死锁概率明显增加。安全不是靠包裹更多操作换来的，而是靠精确划定必须同时成功的最小变更集合。

外部 HTTP 调用为什么不应该长时间包在数据库事务里？因为数据库事务管理的是本地数据一致性，而外部调用具有网络不确定性、超时、重试、对端不可控等特点。把外部调用放在事务里，等于让一个本地一致性单元被外部系统的抖动绑架。数据库连接不释放，锁不释放，接口响应时间却被外部系统拉长。正确思路是：外部调用能前置就前置，能后置就后置；确实需要根据外部结果落库，也尽量让事务短小，或者改用本地消息表、最终一致性等方式。

所以洞见可以归结为一句话：事务的本质是业务一致性边界，而不是 Service 方法装饰器。加注解之前，先问一句：哪些状态必须同时成功？哪些状态允许最终一致？哪些操作根本不应该和数据库写操作绑在同一个事务里？答案清楚了，事务边界自然就出来了。

## 07、行动

给订单创建流程画出事务边界。可以分几步走。

第一步，梳理用例里的全部状态变更：创建订单主记录、扣减库存、创建支付记录、发送通知等。

第二步，圈定必须同时成功的写操作。订单主记录、库存扣减、支付记录创建通常需要写在同一个事务里，因为它们共同表达“下单成功”这个不可拆分的业务事实。

第三步，把外部交互和校验移出事务。参数校验、价格查询、风控检查、外部库存预占等可以在事务前完成；短信、推送、物流等通知类操作放在事务提交后。

第四步，设置明确回滚规则。建议把 rollbackFor 设为 Exception.class，或者清楚列出需要回滚的受检异常，不要依赖默认行为。

第五步，画出边界图：

```text
HTTP 请求
  → 参数校验
  → 外部询价/风控（事务外）
  → [事务边界开始]
       插入订单主记录
       扣减库存
       创建支付记录
     [事务边界结束/提交]
  → 发送短信/通知/物流（事务外）
```

第六步，验证失败路径。故意在扣减库存后、创建支付记录前制造异常，确认三张表都回滚；再模拟外部调用慢的场景，观察连接池占用是否下降。

第七步，把边界写进设计文档。边界不是某一个方法名，而是业务变更的一致范围。以后每次新增字段或新操作，都先判断它属于边界内还是边界外。

## 08、小结

@Transactional 真正的作用是声明一段业务一致性边界。它不是安全符，也不能替代业务边界设计。Spring AOP Proxy 解释了为什么同类内部调用会失效；传播行为决定了事务如何流转；隔离级别和回滚规则影响并发与异常表现；readOnly 和 Flush 各自影响优化与写入时机；MySQL InnoDB 的 ACID 和 MVCC 则决定了底层的可见性与锁行为。订单创建流程如果把这些串起来，就能避免大事务、外部调用进事务、边界过碎这些典型错误。

## 09、链接与概念说明

相关概念速查：

- Spring 事务传播行为：REQUIRED、REQUIRES_NEW、NESTED、MANDATORY 等。
- Spring 事务隔离级别：READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ、SERIALIZABLE。
- Spring 回滚规则：RuntimeException、Error、rollbackFor、noRollbackFor。
- Hibernate/JPA 持久化上下文：flush、commit、readOnly。
- MySQL InnoDB 事务模型：ACID、undo log、redo log、锁类型、MVCC、ReadView、间隙锁、临键锁。
- 事务边界设计：聚合根、用例一致性、本地消息表、最终一致性。

延伸检索建议：在官方文档中搜索 Spring Framework Transaction Management 与 MySQL Reference Manual InnoDB Transaction Model and Locking，能获得更完整的参数说明和锁行为解释。

凌晨两点，运维群弹告警：订单服务数据库连接池耗尽，接口平均响应从 80 毫秒飙到 4 秒，大量下单请求超时。排查发现，一位开发在创建订单的事务里加了一次外部库存预占调用，对端系统抖动，事务一直不提交，连接和锁全部卡住。类似的问题还有很多：有人给方法加上 @Transactional，结果同类方法里内部调用，注解根本不生效；有人把整条下单链路包成一个事务，包含 HTTP、消息、通知，最后锁等待和死锁频发；还有人遇到受检异常不回滚，怀疑框架有问题。

《Spring Boot + JPA 实战》第13招 事务为什么失效

从订单创建实战切入，拆解 Spring 事务代理、传播与隔离级别，讲清事务边界为何不能靠注解兜底，并给出可落地的边界画法。

架构师

编程语言

数据库

开发工具

@Transactional核心是业务一致性边界而非安全开关，需理解Spring AOP代理、传播机制及MySQL InnoDB锁与MVCC。避免大事务与外部调用入事务，精确划定必须同时成功的写操作，用rollbackFor明确回滚规则，确保订单、库存、支付等状态变更原子性。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring Boot + JPA 实战》第13招 事务为什么失效-腾讯云开发者社区-腾讯云

《Spring Boot + JPA 实战》第13招事务为什么失效

《Spring Boot + JPA 实战》第13招事务为什么失效

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Boot + JPA 实战》第13招 事务为什么失效

《Spring Boot + JPA 实战》第13招 事务为什么失效

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Boot + JPA 实战》第13招事务为什么失效

《Spring Boot + JPA 实战》第13招事务为什么失效