Java中事务配合悲观锁实现排他并发控制的核心是数据库加锁与事务边界保障：通过SELECT ... FOR UPDATE等SQL在事务内显式加锁，由数据库引擎管理锁生命周期，事务提交或回滚时自动释放，且需满足事务开启、查询在事务内执行、autocommit=false三条件。
Java 中事务配合悲观锁实现排他并发控制，核心在于「数据库层面加锁 + 事务边界保障」——不是靠 Java 代码自己锁对象，而是让数据库在事务中对数据行（或页、表）施加真实锁，并由事务的 ACID 特性确保锁的持有期与一致性范围严格对齐。
悲观锁在数据库中的本质
Java 应用里的“悲观锁”通常指通过 SQL 显式加锁语句触发数据库的锁机制，常见形式有：
- SELECT ... FOR UPDATE：在可重复读（RR）或读已提交（RC）隔离级别下，对查询到的行加写锁（排它锁），其他事务无法修改或再次加 FOR UPDATE 锁；
- SELECT ... LOCK IN SHARE MODE：加共享锁，允许其他事务读，但阻止写和加排它锁；
- 某些数据库还支持 UPDATE ... WHERE ... 自带隐式排它锁（只要命中索引，锁住匹配行）。
这些锁由数据库引擎（如 MySQL InnoDB）管理，生命周期绑定当前数据库事务：事务提交（COMMIT）或回滚（ROLLBACK）时自动释放。
Java 事务与悲观锁的协同要点
要让悲观锁生效，必须满足三个硬性条件：
立即学习“Java免费学习笔记（深入）”；
- 事务必须开启且未提交：若使用 Spring @Transactional，需确认传播行为是 REQUIRED（默认），且方法未被非事务上下文调用；
- 查询语句必须在事务内执行：例如在 service 方法里先查再改，且查的那句 SQL 带 FOR UPDATE；
- 数据库连接不能自动提交（autocommit=false）：JDBC 连接默认 autocommit=true，必须显式设为 false，否则每条 SQL 独立成事务，锁立刻释放。
示例（Spring Boot + MyBatis）：
@Transactional
public void deductStock(Long itemId, int quantity) {
// 此查询会加行级排它锁，锁住 itemId 对应的记录
Item item = itemMapper.selectForUpdateById(itemId);
if (item.getStock() < quantity) {
throw new IllegalStateException("库存不足");
}
item.setStock(item.getStock() - quantity);
itemMapper.updateById(item); // 修改在同一个事务内完成
}
常见陷阱与规避方式
实际开发中容易失效的典型场景：
- 没走索引导致锁表：FOR UPDATE 若无法使用索引定位，InnoDB 可能升级为表锁，极大降低并发度；务必为 WHERE 条件字段建索引；
- 事务过大或阻塞太久：锁持有时间越长，等待线程越多，可能触发死锁或超时；应尽量缩短事务内操作，避免远程调用、文件 IO 等耗时动作；
- 不同事务以不同顺序加锁：比如事务 A 先锁 item1 再锁 item2，事务 B 反过来，极易形成循环等待；统一按主键升序加锁可破局；
- 读未提交（Read Uncommitted）隔离级别下 FOR UPDATE 无效：该级别不支持真正意义上的悲观锁，应至少使用 READ_COMMITTED。
对比：Java 层 synchronized 不等于事务悲观锁
有人误以为在 service 方法上加 synchronized 就能替代数据库悲观锁，这是严重误区：
- synchronized 是 JVM 进程内锁，只对当前应用实例有效；集群多节点时完全失效；
- 它锁的是方法或对象，不是数据库记录，无法防止其他服务或直连数据库的更新；
- 它不参与事务管理，无法与数据库锁协同，甚至可能因锁粒度错配引发更隐蔽的并发问题。
真正的排他控制，必须下沉到数据库层，由事务兜底。
