1. 悲观锁 (Pessimistic Lock) —— “占着茅坑不拉屎”
核心心态:悲观。我觉得总有人想害朕(想抢我的数据)。
做法:只要我开始用这条数据,我就把门锁死。在我处理完之前,谁也别想碰,连“读”都不行,都在外面排队!
生活比喻:上公厕
- 你进了一个单间。
- 咔嚓,把门插销锁上(数据库行锁)。
- 你在里面玩手机、看报纸(处理业务逻辑)。
- 外面来了 100 个人,推门发现打不开,只能在门口干等着(阻塞 Blocked)。
- 你完事了,开门出来(提交事务 Commit)。
- 下一个人才能进去。
SQL 是怎么写的?
你需要显式地告诉数据库“给我锁上”:
-- 开启事务BEGIN;-- 重点是 FOR UPDATE,这句话一出,这行数据就被你独占了SELECTstockFROMgoodsWHEREid=1FORUPDATE;-- 在这期间,别的线程执行 SELECT ... FOR UPDATE 会被卡死在这里UPDATEgoodsSETstock=stock-1WHEREid=1;COMMIT;-- 只有等你提交了,锁才释放- 优点:绝对安全,数据绝对一致。
- 缺点:性能极差。万一你在里面死锁了或者处理太慢,整个系统就瘫痪了。
- 适用场景:数据极其敏感,且并发量很低(比如银行转账)。
2. 乐观锁 (Optimistic Lock) —— “Git 代码冲突”
核心心态:乐观。我觉得大部分时间没人跟我抢。
做法:我不锁门,大家随便进,随便读。但是我提交修改的时候,我要检查一下,在我修改期间,有没有别人偷着改过数据。
生活比喻:Git 提交代码
- Pull:你和小王都把
index.vue拉到了本地(Version 1)。 - Edit:你在本地改代码,小王也在本地改代码。互不影响。
- Push(关键时刻):
- 小王手快,先提交了(Version 变成 2)。
- 你后提交,Git 告诉你:“冲突了!你的版本(V1)过期了,现在的最新版是 V2。”
- Retry:你只能重新拉取最新代码,合并一下,再提交。
数据库怎么实现?(重点:版本号机制)
通常我们在表里加一个字段:version(版本号)。
- 第一步:查数据
- 线程 A 查到:
stock = 1, version = 1 - 线程 B 查到:
stock = 1, version = 1
- 线程 A 查到:
- 第二步:线程 A 抢先修改
-- 我要把 version 变成 2,前提是现在的 version 必须还是 1UPDATEgoodsSETstock=0,version=2WHEREid=1ANDversion=1;- 结果:成功!数据库里的
version变成了 2。
- 结果:成功!数据库里的
- 第三步:线程 B 慢了一拍去修改
-- B 手里拿的 version 还是 1,它想把 version 变成 2UPDATEgoodsSETstock=0,version=2WHEREid=1ANDversion=1;-- 👈 此时数据库里的 version 已经是 2 了!- 结果:查找条件
version = 1匹配不到任何行。更新失败(影响行数 0)。 - 应用层反应:给用户报错“手慢了”,或者自动重试。
- 结果:查找条件
- 优点:吞吐量极高,不用排队,大家都在跑。
- 缺点:如果冲突太频繁(比如 100 个人抢 1 个),会有 99 个人失败,需要应用层处理重试逻辑。
- 适用场景:互联网大部分场景(秒杀、点赞、评论)。
3. 在 Java (MyBatis-Plus) 里怎么用?
记得我之前推荐你的MyBatis-Plus吗?它把乐观锁封装成了“傻瓜式”操作。
第一步:数据库表里加个字段version,默认值 1。
第二步:Java 实体类加个注解。
publicclassGoods{privateLongid;privateIntegerstock;@Version// 👈 就加这一个注解,告诉 MP 这是乐观锁字段privateIntegerversion;}第三步:配置一下插件(现在的代码里只需要注册一个 Bean)。
第四步:正常写代码。
// 1. 先查出来 (必须先查,拿到当前的 version)Goodsgoods=goodsMapper.selectById(1);// 假设此时 version=1// 2. 修改数据goods.setStock(goods.getStock()-1);// 3. 更新// MyBatis-Plus 会自动把你生成的 SQL 变成:// UPDATE goods SET stock=0, version=2 WHERE id=1 AND version=1intresult=goodsMapper.updateById(goods);if(result==0){return"抢购失败,被人截胡了!";// 没抢到锁}总结
- 悲观锁:
FOR UPDATE。先锁后干。像红绿灯,红灯停绿灯行。 - 乐观锁:
version字段。先干后查。像斑马线,看着没人才走,走到一半发现有车来了就退回来。
在面试里,只要你能说出**“为了性能,我们一般优先使用基于版本号的乐观锁,除非是像金额扣减这种极度敏感的业务才考虑悲观锁”**