Java面试之数据库乐观锁与悲观锁

幻夢星雲 2025-12-31 00:00:00 次阅读

MySQL中乐观锁需应用层实现，常用UPDATE...WHERE version=？模式，通过ROW_COUNT()判断是否更新成功；version字段须为INT/BIGINT，禁用TIMESTAMP。

乐观锁怎么在 MySQL 中实现

乐观锁不是数据库的内置机制，而是应用层基于版本号或时间戳的并发控制策略。MySQL 本身不提供 OPTIMISTIC LOCK 语法，必须靠业务逻辑+唯一约束/条件更新来保障。

最常用的是 UPDATE ... WHERE version = ? 模式：

UPDATE account SET balance = balance - 100, version = version + 1 
WHERE id = 123 AND version = 5;

执行后检查 ROW_COUNT()（JDBC 中为 executeUpdate() 返回值）：

返回 1 → 更新成功，版本已推进
返回 0 → 说明 version 已被其他事务改过，当前操作冲突失败

注意：字段 version 必须是 INT 或 BIGINT，不能用 TIMESTAMP —— 因为高并发下可能毫秒级重复，导致误判丢失更新。

悲观锁在 MySQL 中用 SELECT ... FOR UPDATE 就够了吗

不够。它只在事务内、且满足特定隔离级别和索引条件下才真正加行锁。常见失效场景比想象中多：

没开事务：SELECT ... FOR UPDATE 在自动提交模式下会立刻释放锁，等于没锁
查询没走索引：InnoDB 会升级为表锁（尤其是 WHERE 条件无索引时），严重拖慢并发
使用了非唯一条件：比如 WHERE status = 'pending'，可能锁住所有匹配行甚至间隙，引发锁等待甚至死锁
事务过长：锁持有时间越长，阻塞越严重，还可能触发 Lock wait timeout exceeded

正确写法必须包含：BEGIN 显式开启事务 + 精确主键/唯一索引查询 + 尽快提交。

Java 代码里怎么配合 Spring 处理乐观锁失败

不能靠 try-catch Exception 捕获，因为乐观锁冲突不会抛异常，只会返回影响行数为 0。关键是在 DAO 层判断结果并向上抛出自定义业务异常：

int updated = jdbcTemplate.update(
    "UPDATE order SET status = ?, version = version + 1 WHERE id = ? AND version = ?",
    newStatus, orderId, expectedVersion
);
if (updated == 0) {
    throw new OptimisticLockException("Order " + orderId + " has been modified");
}