乐观锁与悲观锁怎么选？

选择乐观锁还是悲观锁，关键不在于技术优劣或系统整体读写比例，而在于精准识别业务中具体数据的并发修改频率——若同一行记录被争抢的概率低（如社交点赞、草稿保存），乐观锁凭借无锁读、高吞吐和轻量校验更高效；若存在明显热点（如秒杀商品、账户余额），则悲观锁通过提前加锁保障强一致与稳定性；实践中更需关注写操作在关键数据上的并发密度而非总QPS，并结合灰度监控（失败率＞5%或等待超100ms即预警），灵活采用混合策略（如缓存读+数据库悲观扣减、乐观为主+悲观兜底）才能真正匹配业务的真实节奏。

选型核心就一条：看变量被并发修改的频率。冲突少，用乐观锁；冲突高，用悲观锁。不是性能或技术先进性的问题，而是匹配业务真实读写节奏的问题。

冲突低时，乐观锁更轻快

当多个线程/事务大概率不会同时改同一行数据（比如用户资料编辑、文章点赞、订单状态标记），乐观锁靠版本号或时间戳做提交校验，全程不锁表、不阻塞读，吞吐量高、响应快。

• 典型场景：社交类操作（评论更新、关注数+1）、内容管理系统（草稿保存）、非核心库存预扣减
• 关键动作：表里加 version 字段，UPDATE 语句必须带 WHERE id = ? AND version = ?
• 失败后需主动重试（例如 while 循环 + 最大重试次数），不能直接抛错中断业务

冲突高时，悲观锁更稳当

当多个请求极可能争抢同一资源（如秒杀最后一件、账户余额扣款、订单支付锁单），乐观锁会频繁失败重试，反而放大延迟和错误率。此时用悲观锁提前锁定，宁可排队也不乱。

• 典型场景：金融转账、库存强扣减、抢购锁单、订单创建时查重并占位
• 关键动作：在事务内用 SELECT ... FOR UPDATE（行级排他锁），确保后续 UPDATE 不被干扰
• 注意避免长事务——锁持有时间越短越好，否则阻塞面扩大

别只看“读多写少”，要看“谁在写同一行”

表面读多写少，但如果写集中在极少数热点记录（如热门商品ID=1001），那实际冲突频率很高。这时候乐观锁容易雪崩，应倾向悲观锁或引入分段锁、缓存预减等优化手段。

• 判断依据不是总QPS，而是热点数据的写请求并发密度
• 可通过数据库慢日志、锁等待监控（如 information_schema.INNODB_TRX）验证真实冲突情况
• 灰度上线时，重点观察乐观锁的失败率（>5% 就该警惕）、悲观锁的平均等待时长（>100ms 需优化）

混合用法很常见，不是非此即彼

真实系统往往按操作类型或数据层级拆分策略。例如：

• 读库存走缓存（无锁），扣库存走数据库悲观锁（强一致）
• 用户资料页整体用乐观锁，但其中“手机号”字段因校验严格改用悲观锁
• 先用乐观锁尝试更新，失败后降级为悲观锁重试（适合对一致性有兜底要求的场景）

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~