当前位置：首页 > java >正文

乐观锁与悲观锁

java 2025/8/1 19:37:02

悲观锁（Pessimistic Lock）

✅ 核心思想：

始终假设最坏的情况：别人一定会修改数据，所以每次读写都会加锁，确保操作安全。

在读数据时就加锁，防止其他事务修改这条数据，确保当前事务后续的操作（尤其是写）是安全的。

悲观锁就是 “读时加锁，确保写时没有并发冲突”，必须配合事务使用，先查锁定，后更新提交，这是它的核心机制。

🛠 实现方式：

数据库层面的锁（如行锁、表锁）

SELECT * FROM user WHERE id = 1 FOR UPDATE;

该语句会对 id=1 的行加行锁（InnoDB），其他事务只能等你释放。

✅ 解释 SELECT … FOR UPDATE是什么？

这是一个 悲观锁 的实现方式。它会：

给返回的记录加上行级排他锁（exclusive lock）
直到当前事务提交/回滚之前，其他事务不能对这行数据做 UPDATE 或 DELETE

📌 使用场景：

通常用于先读后改的业务逻辑，例如银行扣款：

本质是用于“查询 + 锁定”

BEGIN; -- 开始事务（BEGIN）；-- 查出余额并加锁
SELECT balance FROM account WHERE id = 123 FOR UPDATE;-- 应用层判断余额是否足够，然后扣款
UPDATE account SET balance = balance - 100 WHERE id = 123;COMMIT;

应用场景	原因 / 说明
库存扣减（电商系统）	多用户同时抢购同一个商品，必须保证库存一致性，防止“超卖”现象。
积分/余额变更	如用户领取奖励、消费积分、修改余额等，必须防止并发重复扣减或增加。
用户账户状态变更	某些状态是强一致的，例如实名认证状态不能同时被两个操作修改。
分布式事务关键数据保护	如主业务成功后，写入其他关键表数据（如日志、状态表），必须确保某些步骤不被并发干扰。
任务领取 / 队列消费	多个服务实例抢占任务，使用悲观锁防止任务被重复领取（抢单系统中也常见）。
订单状态流转	比如订单状态从“待支付”到“已支付”，不能被重复更新或被非法修改。
排队/名额抢占操作	比如课程报名、预约挂号、秒杀等，需要严格控制名额。

📌 特点：

并发低、冲突高的系统下比较安全
容易引发锁等待、死锁等问题
对数据库压力大

悲观锁特别适合：

数据写冲突概率高的场景；
强一致性要求高，如金融、电商、任务调度等；
可以接受一定程度的性能牺牲来保证数据正确性。

乐观锁

✅ 核心思想：

默认别人不会修改，只有在提交时检查是否有冲突（比如版本号是否变了），如果有冲突，就放弃本次操作或重试。

🛠 实现方式：

使用版本号或时间戳字段来检测冲突。

示例：

id | name  | version
1  | Tom   | 3

UPDATE user SET name = 'Jerry', version = version + 1
WHERE id = 1 AND version = 3;

表结构：

如果返回 0 行，说明版本冲突；你可以重试或提示失败。

📌 特点：

无需加锁，适合并发量大、冲突少的场景
实现复杂度略高，需业务控制
很适合读多写少的业务（如订单系统、配置系统）

流程

前端/调用方应当在读取数据后，连同 version 一并提交回来，否则服务器无法判断是否有并发修改行为。

查询数据

{"id": 1,"name": "Tom","version": 3
}

前端修改 name，连同 version 提交：

{"id": 1,"name": "Jerry","version": 3
}

后端执行 SQL 判断 version 是否一致：

UPDATE user
SET name = 'Jerry', version = version + 1
WHERE id = 1 AND version = 3;

建议后端接口文档明确要求前端带上 version 字段。
若前端实在无法改，可以：
- 后端先查当前版本（增加一次 DB IO，失去乐观锁“无锁”的优势）；
- 或只能用悲观锁代替（使用 SELECT … FOR UPDATE 加锁）。

版本号字段

目前最主流的乐观锁实现，版本号字段通常就是 int 类型

每次更新时 version + 1，判断是否冲突即可。

❓ 为什么不用 UUID 或时间戳呢？

类型	优点	缺点	是否推荐
int（版本号）	简单高效，支持自增，SQL 快	易被猜测、需要前端传回	✅ 常用方案
timestamp（更新时间）	可读性强，也可用于判断冲突	精度可能不足，容易误判	✅ 也常见（如 updated_at）
uuid（版本标识）	安全、不可猜	更新逻辑复杂，不能自增	❌ 一般不建议用来做版本号

可以将 version 包装为不可修改字段，仅供提交用，或传输时改名，比如：

{"id": 123,"new_value": "XXX","_v": 3   // version
}

应用场景

非常适合以下高并发、读多写少、允许一定冲突重试的场景

应用场景	说明
配置管理系统	大量人读取配置，偶尔修改，修改时需避免冲突（比如灰度配置中心）。
商品库存预读写	多人查看商品详情，实际提交订单时使用乐观锁避免库存扣减冲突（低频冲突）。
用户信息修改	比如修改昵称/头像等用户信息，避免并发提交导致数据覆盖。
内容编辑（博客、文章、文案）	避免两个编辑者同时保存时，互相覆盖编辑内容。
订单更新操作（非支付流程）	如用户备注、订单地址修改，避免覆盖修改内容。
版本控制系统 / 文档协作平台	如 Google Docs、Notion 等，在保存文档前先比对版本。
后台运营系统操作控制	多人后台同时维护资源时避免状态冲突，如运营审核、上下架。
非关键业务的数据采集 / 日志写入控制	冲突可以接受失败或重试，适合乐观锁策略。