数据库 on Fallensakura715's Blog

并发下库存预占与扣减的问题

Fri, 11 Sep 2026 17:28:50 +0000

我翻了翻这个商城项目的库存代码，想把它改造成分布式微服务架构。

在分布式场景下，网络请求不能认为是可靠的，这包括请求超时，重复投递，消息乱序等等情况。这个项目的库存扣减防超卖并不是原子的，只维护一个lock_stock，无法解决库存预占幂等问题，库存属于哪个订单，取消请求应该释放哪一批库存。

原项目的问题

当前的锁库存是这么做的： lock_stock +quantity，SQL 没有判断剩余的库存，Service 若把 Mapper 的影响行数直接当成“预占成功”，这个返回值只能证明某一行被更新，不能证明库存充足，这非常容易超卖。无论 stock - lock_stock 是否足够，只要 SKU 存在，更新都可能成功。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


<update id="updateByPrimaryKeySelective" parameterType="com.macro.mall.model.PmsSkuStock"> 
 update pms_sku_stock 
 <set> 
 <if test="productId != null"> 
 product_id = #{productId,jdbcType=BIGINT}, 
 </if> 
 <if test="skuCode != null"> 
 sku_code = #{skuCode,jdbcType=VARCHAR}, 
 </if> 
 <if test="price != null"> 
 price = #{price,jdbcType=DECIMAL}, 
 </if> 
 <if test="stock != null"> 
 stock = #{stock,jdbcType=INTEGER}, 
 </if> 
 <if test="lowStock != null"> 
 low_stock = #{lowStock,jdbcType=INTEGER}, 
 </if> 
 <if test="pic != null"> 
 pic = #{pic,jdbcType=VARCHAR}, 
 </if> 
 <if test="sale != null"> 
 sale = #{sale,jdbcType=INTEGER}, 
 </if> 
 <if test="promotionPrice != null"> 
 promotion_price = #{promotionPrice,jdbcType=DECIMAL}, 
 </if> 
 <if test="lockStock != null"> 
 lock_stock = #{lockStock,jdbcType=INTEGER}, 
 </if> 
 <if test="spData != null"> 
 sp_data = #{spData,jdbcType=VARCHAR}, 
 </if> 
 </set> 
 where id = #{id,jdbcType=BIGINT} 
</update>

锁库存的时候并不能解决并发问题。整个 Java 方法不会自动变成数据库原子操作。假设 stock = 1、lock_stock = 0，请求 A 和 B 都可能读到 0，并分别把 1 写回数据库。数据库里最终甚至可能仍是 lock_stock = 1，但两个订单都收到了成功结果。这是一次丢失更新，库存数字已经无法反映真实的业务归属。如果改成没有条件的 lock_stock = lock_stock + 1，结果又会变成 lock_stock = 2，同样超过总库存。

1
2
3
4
5
6
7
8


private void lockStock(List<CartPromotionItem> cartPromotionItemList) { 
 for (CartPromotionItem cartPromotionItem : cartPromotionItemList) { 
 PmsSkuStock skuStock = skuStockMapper.selectByPrimaryKey(cartPromotionItem.getProductSkuId()); 
 skuStock.setLockStock(skuStock.getLockStock() + cartPromotionItem.getQuantity());
 // 如果这时候库存没了，还会继续预扣 
 skuStockMapper.updateByPrimaryKeySelective(skuStock); 
 } 
}

1
2
3
4


<sql id="Base_Column_List"> 
 id, product_id, sku_code, price, stock, low_stock, pic, sale, promotion_price, lock_stock, 
 sp_data 
</sql>

1

select <include refid="Base_Column_List" /> from pms_sku_stock where id = #{id,jdbcType=BIGINT}

没有预占流水记录，只有一个锁定库存数量字段。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


CREATE TABLE `pms_sku_stock` (
 `id` bigint NOT NULL AUTO_INCREMENT,
 `product_id` bigint DEFAULT NULL,
 `sku_code` varchar(64) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL COMMENT 'sku编码',
 `price` decimal(10,2) DEFAULT NULL,
 `stock` int DEFAULT '0' COMMENT '库存',
 `low_stock` int DEFAULT NULL COMMENT '预警库存',
 `pic` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '展示图片',
 `sale` int DEFAULT NULL COMMENT '销量',
 `promotion_price` decimal(10,2) DEFAULT NULL COMMENT '单品促销价格',
 `lock_stock` int DEFAULT '0' COMMENT '锁定库存',
 `sp_data` varchar(500) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '商品销售属性，json格式',
 PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=243 DEFAULT CHARSET=utf8mb3 ROW_FORMAT=DYNAMIC COMMENT='sku的库存';

订单A取消时，只知道要释放两件，但无法确认这两件是否属于订单A，这也会带来幂等问题，订单A的取消请求发了两次，就会增加四件，虚增库存。这也导致无法审计，难以实现超时释放库存。

为什么要预占库存

订单业务流程是先下单，再支付/取消，库存会发生变化。如果下单时直接扣库存，取消订单恢复库存的时候不知道扣了多少库存，增加一个预扣字段，就能解决，方便了订单状态管理，这就是预占库存。而且，下单和支付不是一个瞬时事务。如果不预占，用户下单后库存可能被其他人抢走。

但是，预占库存会带来一些问题：在秒杀或热门商品场景下，用户下单而不支付，会让很多库存锁定，正常买家无法正常下单。如果扣库存成功，订单服务挂了，可能出现库存减少但是没有订单的情况。

库存原子更新

这个项目目前是单体项目，一条SQL语句的执行是原子的，所以用条件更新即可防止超卖。

1
2


UPDATE ims_sku_stock SET lock_stock = lock_stock + #{quantity} 
WHERE sku_id = #{skuId} AND stock - lock_stock &gt;= #{quantity}

InnoDB 执行这条 UPDATE 时会对目标库存行加排他锁。并发请求会在这一行上串行，后到的请求会基于更新后的值再次判断条件。因此，“判断库存够不够”和“增加锁定数量”不会被其他事务插入，这一条SQL是原子的。

但是这原子更新就意味着有行锁，秒杀情况下会有大量请求竞争同一行的行锁，库存扣减与数据库交互，性能会受到数据库连接数，IO，锁等等的性能限制。

这条 SQL 解决了超卖，却没有解决幂等。相同请求执行两次，仍会把 lock_stock 增加两次。要识别相同请求，库存预占必须有业务身份。

库存预占幂等

幂等就是同一个业务执行很多次，但是业务效果和执行一次相同。前端的防连点更不能替代服务端幂等设计。

原项目有三个库存量：

stock：当前库存总量；
lock_stock：已预占、尚未确认成交的数量；
stock - lock_stock：当前可售数量。

下单时只增加 lock_stock。支付成功后，同时减少 stock 和 lock_stock；订单取消时只减少 lock_stock。已经确认成交后的退款或退货属于另一条入库流程，不能再调用预占释放接口。

只增加一个 lock_stock 字段仍然不够。它只能表示锁了多少库存，不知道是哪个订单锁的。因此需要一张预占单记录请求和状态，再用预占明细记录每个 SKU 的数量：

还需要设置一个过期字段，再加上扫描主动过期，防止库存被无限占用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


CREATE TABLE ims_reservation (
 reservation_id VARCHAR(64) PRIMARY KEY,
 order_id BIGINT NOT NULL,
 request_hash CHAR(64),
 state VARCHAR(16) NOT NULL,
 expires_at DATETIME(3) NULL COMMENT '预占过期时间',
 created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
 updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
 UNIQUE KEY uk_reservation_order(order_id)
) ENGINE=InnoDB;

CREATE TABLE ims_reservation_item (
 reservation_id VARCHAR(64) NOT NULL,
 sku_id BIGINT NOT NULL,
 quantity INT NOT NULL,
 PRIMARY KEY(reservation_id, sku_id)
) ENGINE=InnoDB;

reservation_id 由订单服务生成。同一个业务请求重试时必须继续使用原 ID，不能每次重试都生成新值。order_id 上的唯一索引进一步限制一个订单只能对应一张预占单。

request_hash 是发现幂等键被误用。服务先合并重复 SKU、按 sku_id 排序，再对订单号和明细计算 SHA-256。同一个 reservation_id 如果带着不同商品或数量再次请求，服务会返回参数冲突，而不是把它当成正常重试。

两张预占表属于同一个库存库时可以加外键，但在分库、归档或高并发写入场景中，外键也会增加迁移和写入约束。

库存预占与释放

预占单有状态迁移：

操作	允许的当前状态	结果	库存变化
`reserve`	`INIT`	`RESERVED`	`lock_stock += quantity`
重复 `reserve`	`RESERVED`	返回 `RESERVED`	无
`confirm`	`RESERVED`	`CONFIRMED`	`stock -= quantity`，`lock_stock -= quantity`
重复 `confirm`	`CONFIRMED`	返回 `CONFIRMED`	无
`release`	`RESERVED`	`RELEASED`	`lock_stock -= quantity`
重复 `release`	`RELEASED`	返回 `RELEASED`	无
`INIT` 是事务内部的中间状态。正常情况下，事务提交后外部只能看到 `RESERVED`；任一 SKU 库存不足时，整个事务回滚，已经增加的其他 SKU 锁定量和预占明细也会一起撤销。

confirm 和 release 都先执行：

1
2
3
4


SELECT order_id, request_hash, state
FROM ims_reservation
WHERE reservation_id = ?
FOR UPDATE;

FOR UPDATE把同一张预占单上的一行加悲观锁。支付确认和取消同时到达时，只有先拿到行锁的一方能完成终态迁移，另一方会看到新的状态并停止修改库存。

当支付和超时释放请求同时到达，如果业务要求按支付发生时间裁决，就要引入支付时间或订单状态作为额外依据，不能只依赖任务执行先后。

超时库存释放

预占成功时写入 expires_at，后端定时任务扫描：

1
2
3
4
5
6


SELECT reservation_id, order_id
FROM ims_reservation
WHERE state = 'RESERVED'
 AND expires_at <= NOW(3)
ORDER BY expires_at
LIMIT 100;

任务要逐条调用同一个 release 方法。这样人工取消、订单超时和任务重试共用一套幂等逻辑。多个库存服务实例可能同时扫到同一张预占单，但 SELECT ... FOR UPDATE 会将释放串行化，后到的实例只会读到 RELEASED。

定时任务需要从另一个 Spring Bean 调用 ReservationService.release，让调用经过 Spring 事务代理；不要在同一个类里用 this.release(...) 自调用。项目还需要启用 @EnableScheduling。

扫描任务解决的是库存服务内部的兜底释放。订单服务仍应在订单取消或支付超时时主动发送释放命令，定时扫描只负责处理漏发、延迟和服务故障留下的预占。

扫描时间要根据支付时限和数据库负载调整。

代码示例

预占库存

INSERT ... ON DUPLICATE KEY UPDATE 让重复请求失败，随后再锁定并检查已存在的预占单。多 SKU 请求使用 TreeMap 按 sku_id 排序，让不同事务尽量以相同顺序锁库存行，从而降低死锁概率。死锁仍可能由其他更新路径引入，生产环境还需要对数据库死锁异常做有限次数重试。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


@Transactional
public String reserve(String reservationId, long orderId, List<Line> lines) {
 validateIdentity(reservationId, orderId);
 Map<Long, Integer> quantities = normalize(lines);
 String hash = fingerprint(orderId, quantities);

 jdbc.update("""
 INSERT INTO ims_reservation(
 reservation_id, order_id, request_hash, state, expires_at
 )
 VALUES (?, ?, ?, 'INIT', TIMESTAMPADD(SECOND, ?, NOW(3)))
 ON DUPLICATE KEY UPDATE reservation_id = reservation_id
 """, reservationId, orderId, hash, reservationTtlSeconds);

 Header header = lockedHeader(reservationId, orderId);
 if ("RELEASED".equals(header.state())) {
 throw new ReservationStateException("RESERVATION_ALREADY_RELEASED");
 }
 if (!hash.equals(header.hash())) {
 throw new IllegalArgumentException("IDEMPOTENCY_PARAMETER_CONFLICT");
 }
 if (!"INIT".equals(header.state())) {
 return header.state();
 }

 for (Map.Entry<Long, Integer> entry : quantities.entrySet()) {
 int quantity = entry.getValue();
 int updated = jdbc.update("""
 UPDATE pms_sku_stock
 SET lock_stock = lock_stock + ?
 WHERE id = ? AND stock - lock_stock >= ?
 """, quantity, entry.getKey(), quantity);
 if (updated != 1) {
 throw new StockUnavailableException(entry.getKey());
 }

 jdbc.update("""
 INSERT INTO ims_reservation_item(reservation_id, sku_id, quantity)
 VALUES (?, ?, ?)
 """, reservationId, entry.getKey(), quantity);
 }

 jdbc.update("""
 UPDATE ims_reservation
 SET state = 'RESERVED', updated_at = NOW(3)
 WHERE reservation_id = ? AND state = 'INIT'
 """, reservationId);
 return "RESERVED";
}

支付后确认

确认时同时减少 stock 和 lock_stock。例如确认前 stock = 10、lock_stock = 2，可售库存是 8；确认两件后变为 stock = 8、lock_stock = 0，可售库存仍是 8。支付只是把两件商品从RESERVED转成CONFIRMED，不会再次占用可售库存。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


@Transactional
public String confirm(String reservationId, long orderId) {
 Header header = lockedHeader(reservationId, orderId);
 if ("CONFIRMED".equals(header.state())) {
 return "CONFIRMED";
 }
 if (!"RESERVED".equals(header.state())) {
 throw new ReservationStateException("RESERVATION_NOT_RESERVED");
 }

 for (Line line : items(reservationId)) {
 int updated = jdbc.update("""
 UPDATE pms_sku_stock
 SET stock = stock - ?, lock_stock = lock_stock - ?
 WHERE id = ? AND stock >= ? AND lock_stock >= ?
 """, line.quantity(), line.quantity(), line.skuId(),
 line.quantity(), line.quantity());
 if (updated != 1) {
 throw new IllegalStateException("INVENTORY_INVARIANT_BROKEN");
 }
 }

 jdbc.update("""
 UPDATE ims_reservation
 SET state = 'CONFIRMED', updated_at = NOW(3)
 WHERE reservation_id = ? AND state = 'RESERVED'
 """, reservationId);
 return "CONFIRMED";
}

取消后释放

释放数量来自 ims_reservation_item，而不是取消请求传入的数量。客户端因此无法多释放库存，同一取消请求重复执行也不会再次减少 lock_stock。

方法开头插入 RELEASED 还有一个用途：处理消息乱序。如果取消消息先到、预占消息后到，取消请求会先写入一张没有明细的 RELEASED 记录。迟到的 reserve 看到该状态后直接拒绝，不会在订单已经取消后重新锁库存。

这段逻辑只处理取消和预占之间的乱序。confirm 早于 reserve 时会被拒绝，因为没有预占明细可供确认。订单服务应在确认预占成功后才允许进入支付流程，并让同一 reservation_id 的命令按顺序投递。如果消息通道不能保证顺序，确认命令需要在预占完成后重试，不能跳过状态检查直接扣库存。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


@Transactional
public String release(String reservationId, long orderId) {
 jdbc.update("""
 INSERT INTO ims_reservation(
 reservation_id, order_id, request_hash, state, expires_at
 )
 VALUES (?, ?, NULL, 'RELEASED', NULL)
 ON DUPLICATE KEY UPDATE reservation_id = reservation_id
 """, reservationId, orderId);

 Header header = lockedHeader(reservationId, orderId);
 if ("RELEASED".equals(header.state())) {
 return "RELEASED";
 }
 if (!"RESERVED".equals(header.state())) {
 throw new ReservationStateException("RESERVATION_CANNOT_RELEASE");
 }

 for (Line line : items(reservationId)) {
 int updated = jdbc.update("""
 UPDATE pms_sku_stock
 SET lock_stock = lock_stock - ?
 WHERE id = ? AND lock_stock >= ?
 """, line.quantity(), line.skuId(), line.quantity());
 if (updated != 1) {
 throw new IllegalStateException("INVENTORY_INVARIANT_BROKEN");
 }
 }

 jdbc.update("""
 UPDATE ims_reservation
 SET state = 'RELEASED', updated_at = NOW(3)
 WHERE reservation_id = ? AND state = 'RESERVED'
 """, reservationId);
 return "RELEASED";
}

超时库存释放

示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public List<ExpiredReservation> findExpired(int limit) {
	if (limit <= 0 || limit > 1000) {
		throw new IllegalArgumentException("INVALID_BATCH_SIZE");
	}
	return jdbc.query("""
			SELECT reservation_id, order_id
			FROM ims_reservation
			WHERE state = 'RESERVED' AND expires_at <= NOW(3)
			ORDER BY expires_at
			LIMIT ?
			""", (rs, rowNum) -> new ExpiredReservation(
			rs.getString("reservation_id"), rs.getLong("order_id")), limit);
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


@Component
public class ReservationExpiryJob {
 private static final Logger LOGGER = LoggerFactory.getLogger(ReservationExpiryJob.class);

 private final ReservationService reservationService;
 private final int batchSize;

 public ReservationExpiryJob(
 ReservationService reservationService,
 @Value("${inventory.reservation-expiry-batch-size:100}") int batchSize) {
 this.reservationService = reservationService;
 this.batchSize = batchSize;
 }

 @Scheduled(fixedDelayString = "${inventory.reservation-expiry-scan-ms:5000}")
 public void releaseExpiredReservations() {
 for (ExpiredReservation reservation : reservationService.findExpired(batchSize)) {
 try {
 // release 通过 Spring 代理进入独立事务，多实例重复扫描也不会重复释放。
 reservationService.release(
 reservation.reservationId(), reservation.orderId());
 } catch (IllegalStateException ex) {
 // 支付确认可能与超时释放同时发生，最终状态由预占单行锁串行决定。
 LOGGER.info("Skip expired reservation {}, reason={}",
 reservation.reservationId(), ex.getMessage());
 } catch (RuntimeException ex) {
 LOGGER.warn("Failed to release expired reservation {}",
 reservation.reservationId(), ex);
 }
 }
 }
}

超时重试可靠性

微服务调用会出现响应超时，调用方如果没收到成功信息，不知道库存服务有没有提交事务。

有了幂等设计，也就是reservation_id，订单服务可以直接重试。

第一次请求没提交，重试正常预占
第一次已经提交没收到成功消息，重试发现RESERVED，直接返回当前状态
同一个 ID 被错误用到另一组商品，request_hash不一致返回冲突
订单已经取消，重试读到RELEASED，不会重新预占

确认和释放逻辑相同，调用方如果超时，继续用reservation_id重试，库存变化最多发生一次。

没有解决分布式事务

@Transactional 只覆盖库存服务自己的数据库，不能同时回滚订单库。以下故障仍然可能发生：

库存预占成功，订单服务在记录结果前挂了
订单取消成功，释放请求没有发出去
支付成功，确认库存的消息重复或延迟到达

一种常见做法是让订单服务在本地事务中同时写订单和 outbox 事件，再由后台任务可靠投递。库存服务按至少一次语义消费命令，并依靠 reservation_id 去重。库存服务处理完成后也可以用 outbox 发布预占结果，订单服务再幂等更新订单状态。

如果仍使用同步 HTTP，原则也不变：订单先落库，再调用库存；遇到超时就使用相同幂等键重试。预占成功但订单流程没有继续时，由主动补偿和 expires_at 兜底释放。

只有在调用方可靠地驱动状态变化、失败命令可以持续重试时，完整业务流程才真正闭环。库存库里的一个本地事务不能代替跨服务一致性方案。

行锁性能瓶颈

条件更新保证了正确性，也意味着热门 SKU 的请求会竞争同一行锁。数据库连接数、事务耗时、磁盘 IO 和锁等待都会限制吞吐量。这个问题不能靠优化 SQL 来消除。

不同的业务可以采用不同的方案。

普通商品场景通常先采用数据库条件更新，因为实现简单、数据源单一，也容易核对。秒杀场景可以考虑请求排队、Redis Lua 原子预扣、库存分段或令牌化，但这些方案会引入缓存和数据库之间的一致性、补偿及对账问题。优化前应先压测确认瓶颈，不能用一套尚未闭环的双写方案替换已经正确的数据库事务。

无论是否引入缓存，预占身份、状态机和幂等语义仍然需要保留。Redis 可以改变竞争发生的位置，不能替代“这批库存属于哪个订单”的业务记录。

先把数据库的库存，预占对账做得可靠，后续的消息可靠投递，缓存预扣和秒杀优化才有可核对和补偿的基础。

Spring 中 @Transactional 的生效条件与失效场景

Mon, 02 Feb 2026 11:08:38 +0000

某天订单系统出现了一个数据不一致问题：用户支付成功了，但订单状态没更新，优惠券却已经被核销。排查后发现，开发同学在 Service 中写了一个内部方法调用， @Transactional 悄无声息地失效了。

这类问题在实际开发中屡见不鲜。要彻底理解 @Transactional 为何失效，我们必须先搞清楚它是如何生效的。

@Transactional 的原理

声明式事务

@Transactional 的本质是 AOP 代理 + 事务拦截器。理解这一点是分析所有生效/失效场景的基础。

当我们在方法上标注 @Transactional 时，Spring 并不会对我们的代码做任何修改。它的魔法在于 代理模式。

Spring 在启动时会扫描所有带有 @Transactional 注解的 Bean，然后为这些 Bean 创建一个代理对象。当外部调用这个 Bean 的方法时，实际上调用的是代理对象，而不是原始对象。代理对象会在调用真实方法前后插入事务管理的逻辑。

没有代理时的调用链：

1

调用方 → 目标对象.方法()

有代理时的调用链：

1

调用方 → 代理对象.方法() → 开启事务 → 目标对象.方法() → 提交/回滚事务

这就是为什么 @Transactional 被称为"声明式事务"——你只需要声明（标注注解），Spring 帮你实现事务管理。但这也意味着， 如果调用绕过了代理对象，事务就不会生效。

代理实现的方式

Spring 支持两种代理方式：

JDK 动态代理：基于接口实现。如果你的 Bean 实现了接口，Spring 默认使用这种方式。代理对象和目标对象实现同一个接口，调用时通过接口方法进入代理逻辑。

CGLIB 代理：基于继承实现。如果你的 Bean 没有实现接口，Spring 会使用 CGLIB 生成一个目标类的子类作为代理。子类覆写了父类的方法，在覆写的方法中加入事务逻辑。

CGLIB 基于继承的特性决定了 final 方法无法被代理，子类无法覆写父类的 final 方法。

事务是如何被拦截和管理的

事务拦截器

Spring 事务的核心拦截器是 TransactionInterceptor，它实现了 MethodInterceptor 接口。每当代理对象的方法被调用时，都会先经过这个拦截器。

拦截器的工作流程如下：

解析事务属性：读取方法上的 @Transactional 注解，获取传播行为、隔离级别、超时时间、回滚规则等配置。
获取事务管理器：根据配置找到对应的 PlatformTransactionManager（如 DataSourceTransactionManager）。
开启事务：调用事务管理器的 getTransaction() 方法，根据传播行为决定是开启新事务还是加入已有事务。
执行业务方法：调用目标对象的真实方法。
处理执行结果：如果方法正常返回，提交事务；如果抛出异常，根据回滚规则决定回滚还是提交。

关键源码

事务的核心处理逻辑在 TransactionAspectSupport 类的 invokeWithinTransaction 方法中：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


protected Object invokeWithinTransaction(Method method, Class<?> targetClass,
 final InvocationCallback invocation) throws Throwable {
 
 // 第一步：获取事务属性
 // 这里会解析 @Transactional 注解的所有配置项
 TransactionAttributeSource tas = getTransactionAttributeSource();
 final TransactionAttribute txAttr = tas.getTransactionAttribute(method, targetClass);
 
 // 第二步：获取事务管理器
 final TransactionManager tm = determineTransactionManager(txAttr);
 
 // 第三步：创建事务（如果需要）
 TransactionInfo txInfo = createTransactionIfNecessary(ptm, txAttr, methodId);
 
 Object retVal;
 try {
 // 第四步：执行真实的业务方法
 retVal = invocation.proceedWithInvocation();
 }
 catch (Throwable ex) {
 // 第五步：异常处理——决定回滚还是提交
 completeTransactionAfterThrowing(txInfo, ex);
 throw ex;
 }
 
 // 第六步：正常返回时提交事务
 commitTransactionAfterReturning(txInfo);
 return retVal;
}

事务回滚规则

在 completeTransactionAfterThrowing 方法中：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


protected void completeTransactionAfterThrowing(TransactionInfo txInfo, Throwable ex) {
 if (txInfo.transactionAttribute.rollbackOn(ex)) {
 // 匹配回滚规则，执行回滚
 txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus());
 }
 else {
 // 不匹配回滚规则，仍然提交！
 txInfo.getTransactionManager().commit(txInfo.getTransactionStatus());
 }
}

默认的回滚规则定义在 DefaultTransactionAttribute 中：

1
2
3


public boolean rollbackOn(Throwable ex) {
 return (ex instanceof RuntimeException || ex instanceof Error);
}

这意味着： 默认情况下，只有 RuntimeException 及其子类，以及 Error，才会触发回滚。 如果抛出的是 IOException、 SQLException 这类受检异常，事务会正常提交。

事务生效五个条件

@Transactional 生效必须同时满足的条件：

Bean 必须由 Spring 容器管理

这是最基本的前提。只有被 Spring 管理的 Bean，Spring 才有机会为其创建代理。如果你手动 new 了一个对象，或者类上没有 @Service、 @Component 等注解，那这个对象就是一个普通的 Java 对象，与 Spring 无关，自然也不会有事务能力。

方法必须是 public

Spring 在解析 @Transactional 注解时，会显式检查方法的访问修饰符。如果方法不是 public，注解会被直接忽略。

这个限制的原因与代理机制有关。JDK 动态代理只能代理接口方法（接口方法默认都是 public）；CGLIB 虽然理论上可以代理非 public 方法，但 Spring 为了保持一致性和明确性，统一要求必须是 public 方法。

必须通过代理对象调用

这是最容易踩坑的地方。即使前两个条件都满足了，如果调用方式绕过了代理对象，事务依然不会生效。典型的场景就是同一个类中的方法互相调用（后面会详细讲解）。

事务管理器必须正确配置

Spring 需要一个 PlatformTransactionManager 来实际管理事务。对于 JDBC 操作，通常是 DataSourceTransactionManager；对于 JPA，是 JpaTransactionManager。如果你使用 Spring Boot，自动配置通常会帮你搞定这一切。但在某些复杂场景（如多数据源），你需要手动指定使用哪个事务管理器。

底层存储引擎必须支持事务

事务是数据库层面的概念。如果你使用的存储引擎不支持事务（如 MySQL 的 MyISAM 引擎），那么无论 Spring 层面怎么配置，事务都不会生效。MySQL 请务必使用 InnoDB 引擎。

事务失效八个场景

同类中的内部方法调用

这是最常见、最隐蔽的失效场景。 假设有这样一段代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


@Service
public class OrderService {
 
 public void createOrder(Order order) {
 // 保存订单
 saveOrder(order);
 // 绑定优惠活动
 bindPromotion(order); // 直接调用本类方法
 }
 
 @Transactional
 public void bindPromotion(Order order) {
 promotionDao.bindOrder(order);
 // 如果这里抛异常，期望回滚
 }
}

开发者的预期是 bindPromotion 方法有独立的事务，如果失败应该回滚。但实际上，这个事务根本不会生效。

原因分析：当外部调用 orderService.createOrder() 时，确实是通过代理对象进入的。但在 createOrder 方法内部调用 bindPromotion 时，此时的 this 指向的是目标对象（原始的 OrderService 实例），而不是代理对象。调用直接发生在目标对象内部，完全绕过了代理层的事务拦截器。

解决方案：

方案一：注入自身的代理对象

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


@Service
public class OrderService {
 
 @Autowired
 private OrderService self; // 注入自己，拿到的是代理对象
 
 public void createOrder(Order order) {
 saveOrder(order);
 self.bindPromotion(order); // 通过代理对象调用
 }
}

方案二：使用 AopContext 获取当前代理

1
2
3
4
5
6
7
8
9


@Service
public class OrderService {
 
 public void createOrder(Order order) {
 saveOrder(order);
 // 需要配置 @EnableAspectJAutoProxy(exposeProxy = true)
 ((OrderService) AopContext.currentProxy()).bindPromotion(order);
 }
}

方案三：将方法拆分到不同的类中这是最推荐的做法，既解决了自调用问题，也符合单一职责原则。

方法不是 public

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


@Service
public class UserService {
 
 @Transactional
 void updateUser(User user) { // 包级别访问权限
 userDao.update(user);
 }
 
 @Transactional
 protected void deleteUser(Long id) { // protected
 userDao.delete(id);
 }
 
 @Transactional
 private void innerUpdate(User user) { // private
 userDao.update(user);
 }
}

以上三种写法， @Transactional 都不会生效。Spring 在 AbstractFallbackTransactionAttributeSource 类中有明确的检查：

1
2
3


if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
 return null; // 返回null表示没有事务属性
}

这个限制的设计初衷是：非 public 方法通常是内部实现细节，不应该暴露给外部调用。如果你需要事务，说明这个方法应该是一个对外的业务入口，理应是 public 的。

异常被 catch 后没有重新抛出

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


@Service
public class PaymentService {
 
 @Transactional
 public void processPayment(Payment payment) {
 try {
 paymentDao.save(payment);
 thirdPartyApi.charge(payment); // 可能抛异常
 } catch (Exception e) {
 log.error("支付失败", e);
 // 异常被吞掉了，方法正常返回
 }
 }
}

这段代码的问题在于： catch 块捕获了异常后，只是打印了日志，没有重新抛出。从事务拦截器的视角来看，方法正常执行完毕并返回了，没有任何异常抛出到方法边界之外。根据前面分析的源码逻辑，正常返回会触发 commitTransactionAfterReturning，事务被提交了。

解决方案：

方法一：重新抛出异常

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@Transactional
public void processPayment(Payment payment) {
 try {
 paymentDao.save(payment);
 thirdPartyApi.charge(payment);
 } catch (Exception e) {
 log.error("支付失败", e);
 throw new RuntimeException("支付处理失败", e); // 重新抛出
 }
}

方法二：手动标记事务回滚

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


@Transactional
public void processPayment(Payment payment) {
 try {
 paymentDao.save(payment);
 thirdPartyApi.charge(payment);
 } catch (Exception e) {
 log.error("支付失败", e);
 // 手动标记当前事务需要回滚
 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
 }
}

抛出了受检异常但没有配置 rollbackFor

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


@Service
public class FileService {
 
 @Transactional
 public void uploadFile(MultipartFile file) throws IOException {
 fileDao.saveMetadata(file);
 
 if (file.getSize() > MAX_SIZE) {
 throw new IOException("文件过大"); // 受检异常
 }
 
 storageService.store(file);
 }
}

这个方法抛出了 IOException，这是一个受检异常（Checked Exception），不属于 RuntimeException 的子类。根据默认的回滚规则，这个异常不会触发回滚，事务会正常提交。

正确写法：

1
2
3
4


@Transactional(rollbackFor = Exception.class) // 指定所有异常都回滚
public void uploadFile(MultipartFile file) throws IOException {
 // ...
}

或者更精确地指定：

1
2
3
4


@Transactional(rollbackFor = {IOException.class, BusinessException.class})
public void uploadFile(MultipartFile file) throws IOException {
 // ...
}

阿里巴巴 Java 开发手册建议， @Transactional 注解应该始终指定 rollbackFor = Exception.class，避免受检异常导致的意外提交。

类没有被 Spring 管理

1
2
3
4
5
6
7
8


// 注意：没有 @Service、@Component 等注解
public class StandaloneService {
 
 @Transactional
 public void doSomething() {
 // 这个类不是 Spring Bean，注解无效
 }
}

使用时如果手动创建实例：

1
2


StandaloneService service = new StandaloneService();
service.doSomething(); // 没有事务

这种情况下，Spring 根本不知道这个类的存在，自然也不会为它创建代理。 @Transactional 注解就是一个普通的注解标记，没有任何运行时效果。

多线程调用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


@Service
public class BatchService {
 
 @Transactional
 public void batchProcess(List<Order> orders) {
 // 使用并行流处理
 orders.parallelStream().forEach(order -> {
 orderDao.save(order); // 每个线程独立，不在主事务中
 });
 
 // 或者手动创建线程
 new Thread(() -> {
 orderDao.save(someOrder); // 新线程，没有事务
 }).start();
 }
}

Spring 的事务信息是存储在 ThreadLocal 中的。 ThreadLocal 的特性是线程隔离：每个线程有自己独立的变量副本。当你创建新线程或使用并行流时，新线程无法访问主线程的事务上下文，因此它们的数据库操作是在没有事务的情况下执行的。

主线程中的事务回滚，不会影响子线程已经提交的操作；子线程的操作失败，也不会导致主线程事务回滚。数据一致性完全无法保证。

解决方案：避免在事务方法中使用多线程，或者为每个线程单独管理事务（但这样就不是同一个事务了）。

使用了 final 或 static

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


@Service
public class FinalService {
 
 @Transactional
 public final void finalMethod() {
 // CGLIB 无法覆写 final 方法
 }
 
 @Transactional
 public static void staticMethod() {
 // static 方法不属于实例，无法被代理
 }
}

对于 final 方法：CGLIB 通过继承目标类来创建代理，但子类无法覆写父类的 final 方法，因此事务拦截逻辑无法插入。

对于 static 方法：静态方法属于类而不是实例，代理对象拦截的是实例方法调用。你调用 FinalService.staticMethod() 时，根本不经过任何代理对象。

底层存储引擎不支持事务

现在 MySQL 默认是 InnoDB 存储引擎，但是如果你的 MySQL 表使用了 MyISAM 引擎：

1
2
3
4


CREATE TABLE orders (
 id INT PRIMARY KEY,
 amount DECIMAL(10,2)
) ENGINE = MyISAM;

MyISAM 引擎不支持事务。无论你的 Java 代码如何配置，数据库层面根本不会开启事务。Spring 的事务管理器以为自己在管理事务，实际上数据库根本不配合。

传播行为的困惑

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


@Service
public class OuterService {
 @Autowired
 private InnerService innerService;
 
 @Transactional
 public void outerMethod() {
 orderDao.createOrder(order); // 操作1
 
 try {
 innerService.innerMethod(); // 这个方法会抛异常
 } catch (Exception e) {
 log.error("内部方法执行失败，但我想继续", e);
 }
 
 orderDao.updateOrderStatus(order); // 操作2，期望能执行
 }
}

@Service 
public class InnerService {
 
 @Transactional // 默认 REQUIRED 传播行为
 public void innerMethod() {
 // 做一些操作后抛出异常
 throw new RuntimeException("业务异常");
 }
}

开发者的预期是： innerMethod 失败后，我在外层 catch 住异常，继续执行后续逻辑。但实际运行时，当执行到 orderDao.updateOrderStatus 时，会抛出 UnexpectedRollbackException，提示事务已被标记为回滚。

原因分析：默认的传播行为是 REQUIRED，表示"如果当前存在事务，就加入该事务"。所以 innerMethod 和 outerMethod 实际上在同一个事务中。当 innerMethod 抛出 RuntimeException 时，事务被标记为 rollback-only（必须回滚）。即使你在外层 catch 住了异常，这个标记仍然存在。当 outerMethod 尝试正常返回时，事务管理器发现事务已被标记为必须回滚，于是抛出异常。

解决方案：如果希望内层方法的失败不影响外层事务，可以使用 REQUIRES_NEW 传播行为：

1
2
3
4


@Transactional(propagation = Propagation.REQUIRES_NEW)
public void innerMethod() {
 // 独立的新事务，回滚不影响外层
}

排查事务问题

开启事务调试日志

在 application.yml 中配置：

1
2
3
4


logging:
 level:
 org.springframework.transaction.interceptor: TRACE
 org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG

代码中检查事务状态

1
2
3
4
5


@Transactional
public void someMethod() {
 boolean isActive = TransactionSynchronizationManager.isActualTransactionActive();
 log.info("当前是否在事务中: {}", isActive); // 应该输出 true
}

检查代理类型

1
2
3
4
5
6
7
8


@Autowired
private OrderService orderService;

public void checkProxy() {
 System.out.println(orderService.getClass().getName());
 // 如果是代理，会输出类似：
 // com.example.service.OrderService$$EnhancerBySpringCGLIB$$xxxxx
}

如果输出的是原始类名，说明没有被代理。

总结

核心原则：

理解代理机制： @Transactional 的生效依赖于 AOP 代理，任何绕过代理的调用都会导致失效。
让异常飞出去：事务的回滚依赖于异常抛出。如果你 catch 了异常，要么重新抛出，要么手动标记回滚。
明确指定 rollbackFor ：不要依赖默认的回滚规则，建议始终配置 rollbackFor = Exception.class。

@Transactional 的本质是通过代理在方法执行前后插入事务管理代码。理解了这一点，所有失效场景都能用"是否经过代理"和"异常是否抛出"这两个问题来分析。