乐观锁和悲观锁是两种并发控制思路，核心区别在于是否提前加锁及对冲突的预判；需据数据竞争强度、一致性要求和操作类型选择：写多用悲观锁（如库存扣减），读多用乐观锁（如商品浏览），强一致选悲观锁，可重试选乐观锁，实际常分层混合使用。
乐观锁和悲观锁不是具体某一个类或接口，而是两种不同的并发控制思路，区别核心在于“是否提前加锁”以及“对冲突发生的预判”。应用时不能凭感觉选，得看数据竞争强度、一致性要求和操作类型。
看写操作频率决定用哪种
写操作频繁、多个线程经常争抢改同一份数据，比如库存扣减、账户余额更新、订单状态变更——这类场景冲突率高（通常＞40%），适合用悲观锁。它通过加锁阻塞其他线程，确保每次修改都独占资源，避免脏写。
- 数据库中常用 SELECT ... FOR UPDATE 或 UPDATE ... WHERE id = ? FOR UPDATE 实现行级悲观锁
- Java 代码里用 synchronized 方法/块 或 ReentrantLock.lock() 显式加锁
- 注意：必须搭配事务使用，否则锁可能不生效；WHERE 条件要走索引，否则可能升级为表锁
看读写比例决定性能取舍
读多写少的场景，比如商品详情页浏览量统计、用户资料查询+偶尔编辑、配置项读取与低频更新——这类操作大部分时间只是读，冲突极少（通常＜20%），用乐观锁更高效。它不阻塞读，只在提交时校验，省去锁开销。
- 数据库中靠 版本号字段（version） 实现：UPDATE ... SET ..., version = version + 1 WHERE id = ? AND version = ?
- Java 中用 AtomicInteger.compareAndSet()、AtomicReference 等 CAS 原子类
- JPA/Hibernate 可直接用 @Version 注解，框架自动注入版本校验逻辑
看一致性容忍度决定失败策略
悲观锁失败是“等”，乐观锁失败是“试”。如果业务不允许任何等待（如实时接口超时严格），又可以接受短暂不一致或重试，就倾向乐观锁；如果必须强一致、不能出错（如金融转账），哪怕慢一点也要用悲观锁保底。
立即学习“Java免费学习笔记（深入）”；
- 乐观锁失败后常见做法：捕获更新影响行为 0，自动重试（带最大次数限制）、返回冲突提示、或降级为补偿事务
- 悲观锁要注意死锁风险：统一按固定顺序加锁、设置锁超时时间、避免长事务
- 高并发下乐观锁若重试频繁（比如秒杀尾部库存），可能引发 CPU 暴涨，此时需结合限流或降级
实际开发中常混合使用
没有银弹。真实系统往往分层用锁：数据库层用悲观锁保底线（如扣库存），服务层用乐观锁提吞吐（如更新缓存计数器），前端加幂等 Token 防重复提交。关键不是非此即彼，而是根据每处数据的访问特征做针对性设计。
