本文系统讲解spring中@transactional注解的事务传播行为与隔离级别原理，结合代码示例与并发风险分析，帮助开发者在高并发场景（如抢码、库存扣减）中避免重复分配、脏读、幻读等一致性问题。
本文系统讲解spring中@transactional注解的事务传播行为与隔离级别原理，结合代码示例与并发风险分析，帮助开发者在高并发场景（如抢码、库存扣减）中避免重复分配、脏读、幻读等一致性问题。
在企业级应用中，仅添加@Transactional注解远不足以保证高并发下的数据安全——尤其当业务逻辑涉及“先查后改”（read-then-write）模式时，如从库存表中查找可用许可码并标记为已分配。您提供的assignFreeCodeToService()方法看似原子，实则存在严重的竞态条件（race condition），极易导致同一许可码被重复分配。
? 问题根源：事务边界 ≠ 数据锁定
您的代码执行流程如下：
@Transactional
public void assignFreeCodeToService(Service service) {
Code code = codeRepository.findFirstByStatus("free").orElseThrow(...); // Step 1: SELECT
code.setStatus("assigned"); // Step 2: 内存修改
codeRepository.save(code); // Step 3: UPDATE
serviceRepository.save(service);
}即使整个方法运行在单个事务中，默认隔离级别（如MySQL的REPEATABLE_READ或PostgreSQL/Oracle的READ_COMMITTED）也无法阻止两个并发事务同时执行Step 1：它们可能几乎同时查到同一条status = "free"的记录，随后各自执行UPDATE，最终造成“双写成功”，严重违反业务约束。
✅ 正确做法不是依赖事务自动加锁，而是显式施加行级排他锁（SELECT ... FOR UPDATE），确保“查”与“改”形成原子性临界区。
✅ 正确实现方案（推荐）
方案一：JPA原生锁查询（最简洁可靠）
@Repository
public interface CodeRepository extends JpaRepository<Code, Long> {
@Query("SELECT c FROM Code c WHERE c.status = 'free' ORDER BY c.id ASC")
List<Code> findFreeCodes();
// 关键：使用LockModeType.PESSIMISTIC_WRITE强制加写锁
@Query("SELECT c FROM Code c WHERE c.status = 'free' ORDER BY c.id ASC")
@Lock(LockModeType.PESSIMISTIC_WRITE)
List<Code> findFreeCodesWithLock();
// 或更精准地锁定单条（推荐）
@Query("SELECT c FROM Code c WHERE c.status = 'free'")
@Lock(LockModeType.PESSIMISTIC_WRITE)
@OrderBy("c.id ASC")
Optional<Code> findFirstFreeCodeWithLock();
}调用方：
@Transactional
public void assignFreeCodeToService(Service service) {
Code code = codeRepository.findFirstFreeCodeWithLock()
.orElseThrow(() -> new ApiException("No available Code"));
code.setStatus("assigned");
codeRepository.save(code); // UPDATE会继承锁，确保原子性
service.setCode(code.getId());
serviceRepository.save(service);
}方案二：数据库原生SQL + FOR UPDATE（兼容性最强）
@Modifying
@Query(value = "UPDATE code SET status = 'assigned', updated_at = NOW() " +
"WHERE id = (SELECT id FROM code WHERE status = 'free' ORDER BY id LIMIT 1) " +
"AND ROW_COUNT() > 0", nativeQuery = true)
int assignOneFreeCode();⚠️ 注意：此方式需配合@Transactional且确保数据库支持子查询锁（MySQL 8.0+ / PostgreSQL均支持）。
? 隔离级别 ≠ 并发解决方案
虽然提升隔离级别（如SERIALIZABLE）理论上可规避部分问题，但：
- 性能代价极高：串行化执行严重限制吞吐量；
- 异常不可控：易触发SerializationFailureException，需额外重试逻辑；
- 非根本解法：它解决的是“事务间可见性”，而非“业务逻辑竞争”。
✅ 最佳实践是：保持默认隔离级别（Isolation.DEFAULT） + 显式悲观锁/乐观锁 + 短事务。
? 关键注意事项总结
| 项目 | 建议 |
|---|---|
| 传播行为 | 默认REQUIRED足够，无需修改；避免NEVER或NOT_SUPPORTED用于写操作 |
| 只读优化 | 查询类方法标注@Transactional(readOnly = true)，提升性能 |
| 锁粒度 | 优先SELECT ... FOR UPDATE单行锁，避免全表扫描锁表 |
| 重试机制 | 对于高并发抢码场景，建议封装带指数退避的重试逻辑（如@Retryable） |
| 唯一约束兜底 | 在数据库code.status字段上添加唯一索引（如(status, code_value)组合索引），作为最后防线 |
✅ 最终结论
@Transactional只是声明了事务边界，不等于自动加锁，也不等于线程安全。在“查-改”型并发场景中，必须主动引入悲观锁（@Lock）或原子更新语句（UPDATE ... WHERE ...），才能真正杜绝重复分配。忽视这一点，无论传播属性如何配置、隔离级别设得多高，都无法保证数据一致性。
真正的并发安全，始于对ACID中Isolation（隔离性）与Concurrency Control（并发控制） 的清醒认知，而非对注解的盲目信任。
