## 01、痛点

你有没有遇到过这样的情况：两个请求同时修改同一个商品价格，前一个请求刚保存成功，后一个请求又把价格改了回去，结果前一个修改像没发生过一样？我是老李。最近在排查一个商品价格偶尔回跳的问题，现象很典型：线上日志显示两次修改都成功，但最终落库的却是旧值。顺着代码一看，两个线程都是先查后改再保存，保存时只按主键定位文档。后写的线程把先写的线程覆盖了。

这类问题在文档型数据库里尤其容易发生。很多服务把 MongoDB 当成一个简单的“持久化地图”，读出一个对象，改几个字段，再整体 save。只要没有并发，这个逻辑没有问题。但一旦两个请求基于同一个旧状态修改同一个 Document，就出现了典型的丢失更新。商品价格、配置编辑、库存快照、用户资料维护，都是这种先读后写模式。

麻烦的是，这种覆盖不是偶发就消失，而是随着服务规模扩大从偶发变成必现。尤其是促销、批量调价、管理后台编辑同时发生时，两个操作可能都基于同一个版本开始。等我们收到客诉时，往往已经覆盖了多次。为什么现在要讲这件事？因为 Spring Data 已经提供了 @Version 这套乐观并发控制，但很多人对它只停留在“知道有这个注解”，并不清楚它真正拦截了什么，以及什么时候不该用它。更关键的是，简单计数、单文档修改、多文档事务这三类问题经常被混在一起处理，导致要么锁太重，要么根本没防住。

## 02、是什么

@Version 是 Spring Data 提供的一个注解，用来给实体增加乐观并发控制。它通常标在一个数值型字段上，比如 Long 或 Integer。每次通过 Spring Data 的保存接口成功写入文档后，这个版本字段会自动加 1。下次更新时，旧版本号会作为过滤条件一起提交给数据库。如果数据库中没有匹配到“主键相同且版本号等于旧值”的文档，说明这个文档已经被别人改过，Spring Data 就会抛出 OptimisticLockingFailureException。

这里的核心不是版本号本身，而是版本号所带来的比较语义。没有版本字段时，更新条件往往只有主键，数据库只判断“这条文档在不在”；有了版本字段后，更新条件变成“这条文档在，而且版本还是我刚读到的那一版”。这就把“基于旧状态修改”这个隐含前提显式化了。数据库在更新时如果影响行数为 0，Spring Data 会把这种静默失败转成异常，上层就可以捕获并决定下一步。

与版本字段配套的是异常与重试。OptimisticLockingFailureException 表示这次写操作没有成功，原因是读取后文档已经被其他请求修改。它不是一个系统错误，而是一种业务冲突信号。处理方式通常有三种：立即失败并提示用户刷新、自动重试、或者转人工介入。自动重试不是简单再 save 一次，而是要重新读取最新文档，把当前业务变更重新应用在新版本上，再保存一次。如果重试仍然失败，可能说明冲突太频繁，需要调整方案。

还有一个很容易被忽略的点：如果这次修改只是对数值字段做简单增减，比如价格加 5 元、库存减 1、访问量加 1，那么不应该先读出来再加完写回。数据库本身支持原子 Update，例如 MongoDB 的 $inc 可以在一条命令里完成“在服务器端对字段加一个值”。这种操作不涉及读旧值，也就没有读改写竞态。所以简单计数仍应优先原子 Update，而不是一上来就加版本号。@Version 更适合“必须读取旧值，根据旧值计算出一个新值，再整体写回”的场景。

## 03、为什么

为什么默认的 save 不够？因为文档型数据库的写操作通常是整体替换或按字段更新，但它不会自动判断你的更新是不是基于旧状态。默认情况下，后写覆盖先写是合法的。业务上我们以为是“我在 100 元基础上改成 120 元”，但数据库看来只是“把这条文档的 price 字段设成 120”。如果另一个线程也在 100 元基础上改成 90 元，最终谁后到谁生效。版本字段把这个隐含的“基于旧状态”变成显式约束，让数据库替我们识别冲突。

为什么选择乐观锁而不是悲观锁？在文档库和大部分业务场景里，读操作远多于写操作，写冲突的概率并不高。乐观锁在读时不加锁，只在写时校验，因此不会阻塞其他读请求，吞吐量更好。悲观锁则需要在读取时就占有锁，直到事务结束，占用资源更多，还容易造成锁等待。对于“两个请求改同一个文档”这种低频冲突，乐观锁的代价更低。只有当冲突非常高时，乐观锁的重试反而会放大压力，这时才应该考虑别的方案。

为什么 Spring Data 帮我们管理版本字段这件事很重要？因为手写版本判断非常容易遗漏。比如一些工程师习惯自己写 Update 语句：先查版本，再 update where id = ? and version = ?。但由于框架封装、命名不一致、批量逻辑绕开等原因，版本条件可能漏掉。Spring Data 的 save 接口会自动读取实体上的 version，把它放到更新条件里，并在成功后加 1。这样对普通写入路径来说，版本控制是默认生效的。但在批量写入或底层模板操作中，情况会有所不同。如果绕过了实体保存过程，直接使用原生批量更新，框架不会自动改 version，需要开发者自己在更新语句里维护。

## 04、架构

从架构角度看，@Version 把一份文档的更新分成了几个层次。最上面是实体映射层，实体对象里有一个版本字段，这个字段不参与业务逻辑，只是并发控制的元数据。中间是 Spring Data 的写入 API 层，保存时判断实体是新建还是更新。如果是更新，就读取当前 version，生成带版本条件的更新语句，并且把 version 加 1。下层是数据库执行层，数据库根据主键和版本号定位文档，执行写入。如果定位不到，就返回影响行数为 0。最上层是应用的重试与决策层，捕获异常后决定重试、放弃还是提示用户。

以 MongoDB 为例，一次普通保存的大致行为可以理解成：更新条件为 `{ _id: 文档ID, version: 旧版本号 }`，更新内容里既有业务字段的变化，也有 `$inc: { version: 1 }`。这样只要旧版本号不匹配，更新就不会命中任何文档。对于关系型数据库，思路类似，更新语句会带 `where version = ?`，版本不匹配时影响行数为 0。

批量写入场景需要单独强调。如果你批量处理的对象每个都是实体调用 save，那么版本字段仍然由 Spring Data 管理，每个实体都会走版本判断。但如果为了性能直接调用底层批量 API，比如 MongoDB 的 bulkWrite 或模板里的 updateFirst，框架不会自动为你维护 version，因为这些操作绕过了实体映射。此时版本号可能停滞不前，乐观锁名存实亡。即使批量写入中只有部分文档需要版本控制，也要保证更新条件中带上 version，并在成功后将其加 1。否则就会出现“普通保存有版本，批量保存没版本”的不一致行为，排查起来非常困难。

重试层也不能放在太底层。典型设计是把重试放在服务方法或仓储包装层，而不是让数据库驱动反复尝试。因为重试需要重新读取文档、重新执行业务计算，这些业务逻辑数据库驱动是不知道的。重试次数一般限制两到三次，避免在冲突高峰时形成雪崩。

## 05、实战

下面用一个商品价格并发修改的例子来说明。假设商品文档的结构是：主键 id、商品名 name、价格 price，还有一个版本字段 version。初始数据是 price = 100，version = 1。

两个线程同时操作这个商品。线程 A 先加载文档，读到 price = 100，version = 1。线程 B 也几乎同时加载，读到相同的 price = 100，version = 1。线程 A 想把价格改成 120，调用 save。Spring Data 会带上 version = 1 作为更新条件，执行成功后，数据库里的文档变成 price = 120，version = 2。线程 B 想把价格改成 90，也调用 save。但线程 B 手上拿到的旧版本号还是 1，更新条件变成 version = 1。此时数据库里版本号已经是 2，条件匹配不到文档，Spring Data 抛出 OptimisticLockingFailureException。

如果没有 @Version，线程 B 的更新条件只有主键，它会正常地把 price 改成 90，最终线程 A 的 120 被覆盖掉。数据库不会报任何错，因为主键确实存在。线程 A 的修改就这样无声无息地消失了。加上版本字段后，冲突从“事后发现丢数据”变成“写入时抛异常”，这是质的区别。

实体定义可以很简单：

```
@Document
public class Product {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    @Version
    private Long version;
}
```

重试逻辑可以这样写：

```
public void updatePrice(String id, BigDecimal newPrice) {
    for (int i = 0; i < 3; i++) {
        Product product = productRepository.findById(id).orElseThrow();
        product.setPrice(newPrice);
        try {
            productRepository.save(product);
            return;
        } catch (OptimisticLockingFailureException e) {
            // 冲突后重新读取并重试
        }
    }
    throw new IllegalStateException();
}
```

这里没有展示每次重试之间的退避策略，但在实际系统中可以加入短暂随机休眠，避免两个线程同时重试再次撞车。重试次数也不是越多越好。如果重试三次仍然失败，说明当前修改的冲突频率可能已经不适合乐观锁，需要考虑把部分字段改成原子更新，或把并发修改收敛到串行队列。

## 06、洞见

所有并发问题都用乐观锁，看起来好像安全，其实并不合理。乐观锁并不是免费的，它把冲突从数据库层转移到了应用层。每次冲突都意味着一次失败的写请求，以及一次重新读、重新计算、重新保存的成本。如果冲突很少，这个成本可以忽略；如果冲突频繁，重试请求集中到达，会放大数据库和应用的压力。更糟的是，有些简单操作本来一条命令就能完成，加了乐观锁后反而变成先读、再判断、再写、再处理异常，链路变长，竞态窗口变大。

能表达成数据库原子操作的问题，就不要先升级成复杂锁机制。比如“价格加 5 元”本质是一个加法，数据库端执行一次 $inc 即可，不需要知道当前价格是多少，也不会因为别人也在加而覆盖。再比如“数组追加一个元素”“布尔字段翻转”，都有对应的原子更新操作。使用原子更新，数据库会在单条写入中完成比较和修改，应用层无需重试，也不需要版本字段。只有在修改依赖旧值、依赖多字段之间的业务规则、或者需要整体替换文档结构时，才值得引入 @Version。

同时，乐观锁也不是事务的替代品。单文档乐观锁只解决单文档的读改写冲突，无法保证多个文档之间的强一致。如果一个操作需要修改订单、库存、用户余额三个文档，并且要求要么全成功要么全失败，那么仅靠各自的 version 字段不够。跨文档操作需要事务或最终一致性方案。反过来，如果一上来就为简单的单文档修改开事务，也会带来锁等待、性能下降和复杂度上升。选择机制的关键不是“哪个更强”，而是“当前写入语义到底需要哪种保障”。

## 07、行动

结合上面的分析，可以把常见并发修改分成三类，并分别匹配工具。

第一类是单字段数值增减，适合 $inc。例如库存扣减、访问计数、余额累加，只要业务逻辑可以表达为加或减一个值，就应该用数据库原子 Update。优势是不需要读旧值，没有版本冲突，也就没有重试。限制是它只适合简单的数值变化，如果价格要根据会员等级、促销规则计算后替换，$inc 就不够用。

第二类是单文档“先读后改整体覆盖”，适合 @Version 乐观锁。例如商品价格调整、文档配置修改、用户资料编辑。这类操作必须读取旧文档，根据旧状态计算出新状态，然后整体写回。加版本字段可以让并发冲突显式化，捕获异常后重试。限制是冲突不能太高，而且重试要重新执行业务逻辑。

第三类是多文档强一致，适合事务。例如下单扣库存、转账、多表状态同步。事务保证这些操作要么全成功，要么全失败。但事务成本高，尤其是分布式环境或文档库事务，可能会有锁等待和性能开销。事务的范围要尽量小，执行时间要短，避免把耗时业务逻辑包在事务里。

具体行动清单可以这样列：先问这次写操作是不是单字段增减，如果是，直接用 $inc；如果不是，再问是否必须读取旧文档整体修改，如果是，加 @Version 并写清楚重试策略；如果涉及多个文档，且业务要求强一致，再用事务；同时检查批量写入路径有没有绕过版本管理，如果绕过了就要手动补上；最后监控乐观锁冲突率，如果重试越来越频繁，说明可能选错了机制，要考虑拆字段、改原子操作或串行化。

## 08、小结

@Version 是 Spring Data 给单文档写入提供的乐观并发控制，它用一个版本字段把“基于旧状态修改”这件事从隐式变成显式。版本不匹配时，写入失败并抛出 OptimisticLockingFailureException，应用层可以选择重试。但版本字段不是所有并发问题的答案。单字段数值变化优先用原子 Update，单文档整体修改用 @Version，多文档强一致才需要考虑事务。机制的选择顺序，应该由写入语义决定，而不是由习惯决定。

## 09、链接与概念说明

概念说明：

- @Version：Spring Data 注解，标注在实体字段上，用于乐观并发控制。通过保存接口写入时自动递增版本号，并把旧版本号作为更新条件。
- OptimisticLockingFailureException：Spring 框架中的异常，表示更新时版本号匹配失败，通常意味着读取后文档已被其他操作修改。
- $inc：MongoDB 原子更新操作符，对数值字段做加减操作，不需要先读后写。
- 原子 Update：数据库在单条更新语句内完成修改，不经过应用层读改写，可避免并发覆盖。
- 事务：数据库或框架提供的多操作一致性单元，支持回滚，用于多文档强一致场景。

参考路径：Spring Data MongoDB Reference、MongoDB Update Operators、Spring Framework 异常体系。

以上概念可在对应官方文档中查看更详细的行为说明。

你有没有遇到过这样的情况：两个请求同时修改同一个商品价格，前一个请求刚保存成功，后一个请求又把价格改了回去，结果前一个修改像没发生过一样？我是老李。最近在排查一个商品价格偶尔回跳的问题，现象很典型：线上日志显示两次修改都成功，但最终落库的却是旧值。顺着代码一看，两个线程都是先查后改再保存，保存时只按主键定位文档。后写的线程把先写的线程覆盖了。

《Spring Mongo实战》第9招 乐观锁怎么做

多个请求基于旧状态改同一文档时，@Version 能检测冲突并重试。但计数优先用原子更新，事务与乐观锁各有边界，本文用商品价格并发修改讲清选择逻辑。

架构师

数据库

编程语言

后端

Spring Data @Version乐观锁解决MongoDB并发更新丢失问题，通过版本号拦截旧状态覆盖，支持异常重试，区分原子$inc、单文档整体修改及多文档事务场景，提升数据一致性。

关系型数据库

代码解释

大数据

服务器

MongoDB

腾讯云数据库特惠，新用户首单0.5折起


mongodb

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring Mongo实战》第9招 乐观锁怎么做-腾讯云开发者社区-腾讯云

《Spring Mongo实战》第9招乐观锁怎么做

《Spring Mongo实战》第9招乐观锁怎么做

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Mongo实战》第9招 乐观锁怎么做

《Spring Mongo实战》第9招 乐观锁怎么做

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Mongo实战》第9招乐观锁怎么做

《Spring Mongo实战》第9招乐观锁怎么做