Java并发写冲突解决与锁选择技巧

本文深入剖析了Java并发中“写写冲突”的本质——并非简单的多线程改同一变量，而是非原子性的“先查后改再存”操作导致中间状态被覆盖，并指出synchronized因粒度粗、阻塞强、无法跨进程等缺陷，在读多写少、含I/O或分布式场景下反而会严重拖垮性能；进而系统对比了乐观锁（CAS+version校验，轻量但需合理重试）与悲观锁（SELECT FOR UPDATE，稳妥但易引发锁争用和死锁）的适用边界，强调选型必须结合冲突频率、操作耗时和部署范围三大维度，同时点破诸多实战陷阱，如version字段必须与业务更新原子执行、FOR UPDATE需在正确事务隔离级别下使用等，为高并发数据一致性方案提供清晰、落地的技术决策指南。

写写冲突到底是什么，为什么不能靠 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），但那是另一套问题了。

• 冲突频率低于 5%：优先乐观锁 + 有限重试
• 单次写操作含远程调用或文件 I/O：别用悲观锁，等不起，换异步补偿或状态机
• 微服务间共享 DB：乐观锁 version 字段依然有效；但若各自连不同库，version 失效，得靠业务层协调或全局序列号
• 最容易被忽略的一点：乐观锁的 version 更新必须和业务字段更新在同一个 SQL 里完成，分开两条 UPDATE 语句就失去意义

今天关于《Java并发写冲突解决与锁选择技巧》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！