本文介绍如何在 spring boot 多进程/多节点环境下安全地并发读取和更新同一数据库表，重点对比乐观锁与悲观锁的适用场景、实现方式及最佳实践。
本文介绍如何在 spring boot 多进程/多节点环境下安全地并发读取和更新同一数据库表，重点对比乐观锁与悲观锁的适用场景、实现方式及最佳实践。
在分布式微服务架构中，多个 Spring Boot 实例（部署在不同服务器或容器中）常需同时访问同一张数据库表——例如定时任务协同处理订单队列、库存扣减、积分同步等场景。此时，简单的应用层互斥（如 ShedLock）虽能防止重复执行，但其本质是“全局排他调度”，即只允许一个节点执行任务，无法满足“所有节点可并行读写、但保证数据一致性”的真实需求。
真正的解法在于数据库层面的并发控制机制，Spring Data JPA 原生支持两种成熟方案：乐观锁（Optimistic Locking） 和 悲观锁（Pessimistic Locking），二者均作用于具体数据行（row-level），而非整张表，因此既能保障强一致性，又不牺牲吞吐量。
✅ 乐观锁：轻量高效，适合读多写少场景
通过版本号（@Version）字段实现。每次更新时，JPA 自动校验当前记录的版本是否与查询时一致；若不一致（说明已被其他事务修改），则抛出 OptimisticLockException，由业务决定重试或告警。
@Entity
public class Inventory {
@Id private Long id;
private Integer quantity;
@Version
private Integer version; // 自动管理，无需手动赋值
}// 更新逻辑示例（含重试）
@Transactional
public void deductStock(Long itemId, int amount) {
Inventory inventory = inventoryRepository.findById(itemId).orElseThrow();
if (inventory.getQuantity() < amount) {
throw new IllegalStateException("Insufficient stock");
}
inventory.setQuantity(inventory.getQuantity() - amount);
try {
inventoryRepository.save(inventory); // 若版本冲突，此处抛异常
} catch (OptimisticLockException e) {
// 可选择重载后重试，或返回失败
throw new ConcurrentUpdateException("Stock updated by another node", e);
}
}⚠️ 注意：乐观锁不阻塞读操作，但要求业务能容忍偶发更新失败，并具备幂等性设计（如结合唯一业务ID防重）。
✅ 悲观锁：强一致性，适合高冲突写场景
通过数据库行锁（如 SELECT ... FOR UPDATE）显式加锁，阻塞其他事务对同一行的写入（甚至读取，取决于隔离级别）。Spring 提供 @Lock(LockModeType.PESSIMISTIC_WRITE) 或 EntityManager.lock() 方式声明。
@Repository
public interface InventoryRepository extends JpaRepository<Inventory, Long> {
@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT i FROM Inventory i WHERE i.id = :id")
Optional<Inventory> findForUpdate(@Param("id") Long id);
}@Transactional
public void deductStockWithPessimisticLock(Long itemId, int amount) {
Inventory inventory = inventoryRepository.findForUpdate(itemId)
.orElseThrow(() -> new EntityNotFoundException("Inventory not found"));
if (inventory.getQuantity() < amount) {
throw new IllegalStateException("Insufficient stock");
}
inventory.setQuantity(inventory.getQuantity() - amount);
inventoryRepository.save(inventory); // 锁在事务提交时自动释放
}⚠️ 注意：悲观锁会降低并发度，可能引发死锁（需按固定顺序加锁），且依赖数据库事务隔离级别（推荐
REPEATABLE READ或SERIALIZABLE）。
? 总结建议
- 优先选用乐观锁：适用于库存、账户余额等变更频率中低、业务可接受少量重试的场景；实现简单、性能优异、无死锁风险。
-
谨慎使用悲观锁：适用于金融级强一致性要求（如秒杀扣款）、写冲突极高且重试成本过大的场景；务必配合超时机制（如
@QueryHint设置org.hibernate.timeout）避免长事务阻塞。 - 切勿混合使用：同一业务逻辑中避免同时启用乐观与悲观锁，易导致语义混乱与调试困难。
- 补充防护：无论哪种锁，都应结合数据库唯一约束、应用层幂等标识、分布式ID等手段构建纵深防御体系。
通过合理选用 JPA 内置锁机制，你无需引入额外中间件，即可在 Spring Boot 多节点环境中实现安全、高效、可扩展的数据并发访问。
