本文详解如何在 Spring Boot 中通过乐观锁机制确保多线程调用 /doTask 接口时，员工状态（FREE→BUSY）变更的原子性与可见性，避免竞态条件导致重复分配任务。
本文详解如何在 spring boot 中通过乐观锁机制确保多线程调用 `/dotask` 接口时，员工状态（free→busy）变更的原子性与可见性，避免竞态条件导致重复分配任务。
在高并发场景下，仅靠 @Transactional 注解无法解决你遇到的核心问题：多个线程同时读取到 status = FREE，各自执行 UPDATE ... SET status = 'BUSY'，最终可能全部成功（尤其当数据库隔离级别为 READ_COMMITTED 且无显式锁时），造成同一员工被重复分配任务——这正是典型的“读-改-写”竞态（Race Condition）。@Transactional 保证的是单次数据库操作的原子性与回滚能力，但不提供跨事务的读取一致性保障，更无法阻止并发线程基于过期快照做出决策。
✅ 正确解法：乐观锁 + 业务校验 + 原子状态更新
1. 引入版本字段（Optimistic Locking）
在 Employee 实体中添加 @Version 字段，由 JPA 自动管理：
@Entity
public class Employee {
@Id
private Long id;
@Enumerated(EnumType.STRING)
private EmployeeStatus status; // FREE, BUSY
private Integer age;
@Version
@Column(name = "version")
private Integer version; // 初始值为 0，JPA 自动递增
// constructors, getters, setters...
}
✅ 作用：每次
UPDATE操作会自动附加WHERE version = ?条件；若版本不匹配（说明已被其他事务修改），JPA 抛出OptimisticLockException，事务自动回滚。
2. 实现幂等、原子的任务分配逻辑
关键在于：一次数据库操作完成“检查+更新”，避免先 SELECT 后 UPDATE 的两步陷阱：
@Service
@Transactional
public class TaskAssignmentService {
@PersistenceContext
private EntityManager entityManager;
public Result assignTask(Long employeeId) {
try {
// 1. 使用 JPQL 执行带条件的原子更新（推荐：无 N+1 查询，强一致性）
int updated = entityManager.createQuery(
"UPDATE Employee e SET e.status = :newStatus, e.version = e.version + 1 " +
"WHERE e.id = :id AND e.status = :oldStatus AND e.version = :version")
.setParameter("id", employeeId)
.setParameter("oldStatus", EmployeeStatus.FREE)
.setParameter("newStatus", EmployeeStatus.BUSY)
.setParameter("version", getCurrentVersion(employeeId)) // 见下方说明
.executeUpdate();
if (updated == 1) {
return Result.success("Task assigned to employee " + employeeId);
} else {
return Result.failure("Employee is not available (already busy or version mismatch)");
}
} catch (OptimisticLockException e) {
return Result.failure("Concurrent update conflict — employee state changed");
}
}
// 辅助方法：安全获取当前版本（可选，若使用原生 SQL 或需精确控制）
private Integer getCurrentVersion(Long id) {
return entityManager.find(Employee.class, id).getVersion();
}
}
⚠️ 更简洁健壮的实践（推荐）：直接使用 EntityManager.merge() + 状态校验
@Transactional
public Result assignTask(Long employeeId) {
Employee employee = entityManager.find(Employee.class, employeeId);
if (employee == null) {
return Result.failure("Employee not found");
}
// 业务层显式校验：只允许从 FREE 变更为 BUSY
if (!EmployeeStatus.FREE.equals(employee.getStatus())) {
return Result.failure("Employee is already busy");
}
// 更新状态（merge 会触发乐观锁检查）
employee.setStatus(EmployeeStatus.BUSY);
entityManager.merge(employee); // 若 version 不一致，此处抛 OptimisticLockException
return Result.success("Task assigned");
}
3. 控制器层统一异常处理
捕获 OptimisticLockException 并返回友好提示：
@RestController
public class TaskController {
@PostMapping("/doTask")
public ResponseEntity<result> doTask(@RequestParam Long employeeId) {
return ResponseEntity.ok(taskAssignmentService.assignTask(employeeId));
}
}
// 全局异常处理器
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(OptimisticLockException.class)
public ResponseEntity<result> handleOptimisticLock(OptimisticLockException ex) {
return ResponseEntity.status(409).body(Result.failure("Employee is currently being assigned a task — please retry"));
}
}</result></result>
⚠️ 关键注意事项（避坑清单）
- ❌ 不要在事务内做远程调用、文件IO或
Thread.sleep()：会长时间持有数据库连接与行锁，引发性能瓶颈甚至死锁； - ❌ 禁止
try-catch吞掉OptimisticLockException而不回滚：否则事务继续提交，导致数据不一致； - ✅
@Transactional必须作用于 public 方法，且调用需经 Spring 代理（避免同类自调用失效）； - ✅ 前端应支持幂等重试：对
409 Conflict响应建议客户端指数退避后重试； - ✅ 数据库表必须有
version字段且类型支持自增（如INT/BIGINT），初始值设为0。
总结：为什么乐观锁是此场景最优解？
| 方案 | 是否解决竞态？ | 是否阻塞其他请求？ | 是否适合高并发？ | 实现复杂度 |
|---|---|---|---|---|
synchronized（JVM 锁） |
❌（仅限单机，跨实例失效） | ✅（严重阻塞） | ❌（QPS 断崖下跌） | 低 |
数据库 SELECT FOR UPDATE（悲观锁） |
✅ | ✅（阻塞读） | ⚠️（锁粒度大，易死锁） | 中 |
| 乐观锁 + 原子 UPDATE | ✅ | ❌（无锁等待，失败快速响应） | ✅（高吞吐、低延迟） | 低（JPA 原生支持） |
✅ 最终效果：100 个并发请求调用
/doTask?employeeId=1，仅 1 个成功返回BUSY，其余 99 个在毫秒级内收到明确拒绝响应，数据库层面零脏写、零幻读，完美满足“员工一次只做一件事”的业务契约。
