冲突指多线程无协调地对同一数据执行非原子性更新（如先查后改再存），导致中间态被覆盖；synchronized 锁粒度大、阻塞强，无法解决分布式冲突，且在读多写少或含I/O场景下严重拖累吞吐。
写写冲突到底是什么，为什么不能靠 synchronized 硬扛
写写冲突不是“两个线程同时改一个变量”这么简单，而是指多个线程在无协调下对同一份数据执行**非原子性更新操作**（比如先查再改再存），导致中间态被覆盖。synchronized 能锁住代码块，但锁粒度大、阻塞强，在高并发读多写少场景下容易成为瓶颈，且无法解决分布式环境下的冲突。
- 典型现象：
balance = balance + 1在并发下调用多次，最终结果却只加了 1 次 - 根本原因：该表达式包含读取、计算、写入三步，JVM 不保证这三步的原子性
- synchronized 的代价：每次写都要排队，吞吐量直线下滑，尤其当临界区里有 I/O 或远程调用时更明显
乐观锁怎么用：CAS + version 字段是标配
乐观锁不锁数据，而是靠“验证再提交”——每次更新都带上一个版本号或时间戳，数据库/内存检查当前值是否仍匹配，匹配才写入并递增 version；不匹配就失败重试。Java 里最常用的是 AtomicInteger 的 compareAndSet，或者 JPA 的 @Version 注解。
- 数据库层：必须加
version或timestamp字段，UPDATE 语句要带WHERE version = ?条件 - JPA 示例：
@Version private Integer version;，JPA 会自动在 UPDATE 中加入 version 校验 - 纯内存场景：
AtomicInteger.compareAndSet(expected, updated)返回 false 就说明被别的线程抢先改了，得重算逻辑再试 - 坑点：重试逻辑不能无限循环，要加最大重试次数（比如 3–5 次），否则 CPU 打满还卡死
悲观锁什么时候不得不用：SELECT FOR UPDATE 不是万能解药
悲观锁本质是提前占位，适合写冲突概率高、业务逻辑复杂、重试成本远高于等待的场景。但 SELECT FOR UPDATE 是数据库行锁，锁住期间别的事务连 SELECT 都可能被阻塞（取决于隔离级别和索引），而且只在事务内有效。
- 必须满足：SQL 查询条件命中索引，否则升级为表锁，整个表写不了
- MySQL InnoDB 下，
SELECT ... FOR UPDATE只在REPEATABLE READ或更高隔离级别生效；READ COMMITTED下可能锁不住间隙，引发幻读 - Spring 中用
@Transactional(isolation = Isolation.REPEATABLE_READ)+SELECT FOR UPDATE才稳妥 - 别踩的坑：在非事务方法里调用带
FOR UPDATE的查询，锁会立刻释放，等于白加
选型关键看三点：冲突频率、操作耗时、部署范围
没有银弹。本地单机、高频写冲突、逻辑不可拆分 → 悲观锁更稳；分布式、低冲突、纯数值累加 → 乐观锁更轻量；跨服务、无共享存储 → 得上分布式锁（如 Redis + Lua），但那是另一套问题了。
立即学习“Java免费学习笔记（深入）”；
- 冲突频率低于 5%：优先乐观锁 + 有限重试
- 单次写操作含远程调用或文件 I/O：别用悲观锁，等不起，换异步补偿或状态机
- 微服务间共享 DB：乐观锁 version 字段依然有效；但若各自连不同库，version 失效，得靠业务层协调或全局序列号
- 最容易被忽略的一点：乐观锁的 version 更新必须和业务字段更新在同一个 SQL 里完成，分开两条 UPDATE 语句就失去意义
