本文介绍如何在 spring boot 多实例部署场景下，安全、高效地支持多个进程同时读取和更新数据库同一张表，重点对比乐观锁与悲观锁的适用场景，并提供可落地的 jpa 实现方案。
本文介绍如何在 spring boot 多实例部署场景下，安全、高效地支持多个进程同时读取和更新数据库同一张表，重点对比乐观锁与悲观锁的适用场景，并提供可落地的 jpa 实现方案。
在微服务或集群化部署中，多个 Spring Boot 实例（跨机器或容器）常需并发访问同一张数据库表——例如定时任务同步库存、分布式订单状态更新、或共享配置刷新等场景。此时，ShedLock 等分布式调度锁并不适用，因为它通过抢占式加锁强制串行执行，违背了“多进程需并行运行”的核心诉求。真正需要的是数据级并发控制机制：允许多个进程同时读取，但在写入时自动规避脏读、丢失更新等竞态问题。
Spring Data JPA 原生支持两种成熟的数据一致性保障策略：乐观锁（Optimistic Locking） 和 悲观锁（Pessimistic Locking），二者均基于数据库行级锁，无需额外中间件，开箱即用。
✅ 乐观锁：轻量高效，适合读多写少场景
适用于并发冲突概率低、业务逻辑以查询为主、更新频次较低的场景（如用户资料修改、文章点赞计数）。其实现依赖 @Version 字段：
@Entity
public class Product {
@Id private Long id;
private String name;
private Integer stock;
@Version // JPA 自动管理版本号（如 Integer 或 Timestamp）
private Integer version;
// constructors, getters, setters...
}当执行 save() 时，JPA 自动生成带 WHERE version = ? 条件的 UPDATE 语句。若版本不匹配（说明已被其他事务更新），抛出 OptimisticLockException，开发者需捕获并重试或提示冲突：
@Transactional
public void decreaseStock(Long productId, int quantity) {
Product product = productRepository.findById(productId).orElseThrow();
if (product.getStock() < quantity) {
throw new IllegalStateException("Insufficient stock");
}
product.setStock(product.getStock() - quantity);
try {
productRepository.save(product); // 若失败，version 不匹配 → 异常
} catch (OptimisticLockException e) {
throw new BusinessException("Concurrent update conflict, please retry");
}
}⚠️ 注意：乐观锁不阻塞读操作，但要求业务层处理异常与重试逻辑；版本字段必须为非空且初始值合理（如
0或1）。
✅ 悲观锁：强一致性，适合高冲突写场景
当更新频繁、业务无法容忍重试（如金融扣款、秒杀库存预占），应选用悲观锁，由数据库直接锁定目标行，阻止其他事务修改直至当前事务结束：
// 使用 EntityManager 手动加锁（READ / WRITE）
Product product = entityManager.find(Product.class, productId,
LockModeType.PESSIMISTIC_WRITE); // 阻塞其他写，允许并发读
// 或在 Repository 中声明查询方法（JPA 2.0+）
@Query("SELECT p FROM Product p WHERE p.id = :id")
@Lock(LockModeType.PESSIMISTIC_WRITE)
Optional<Product> findForUpdate(@Param("id") Long id);执行时将生成 SELECT ... FOR UPDATE（MySQL/PostgreSQL）或等效语句，确保获取数据后独占该行。注意：锁持有时间 = 事务持续时间，务必控制事务粒度，避免长事务导致锁堆积。
? 总结选型建议
- 优先尝试乐观锁：实现简洁、无数据库锁开销、扩展性好，配合幂等设计与简单重试即可满足大多数分布式更新需求；
- 谨慎使用悲观锁：仅在强一致性不可妥协且能严格管控事务边界时采用，需警惕死锁与性能瓶颈；
- 避免自行实现“应用层锁”（如 Redis 分布式锁 + 业务逻辑判断）：易出错、难维护，且无法替代数据库 ACID 保证。
通过合理选用 JPA 内置锁机制，无需引入复杂协调组件，即可在 Spring Boot 多节点环境中实现安全、高效的并发数据访问。
