所谓的“Zui佳实践”Ru果不加甄别地套用，往往会变成Zui大的坑。

这次排查给我Zui大的感触是：并发问题的解决方案必须与事务模型匹配。乐观锁的适用前提是"冲突少、重试成本低"，但它有一个隐含假设——重试时Neng读到Zui新数据。在大事务的快照隔离下这个假设不成立。今天我想聊聊我是如何从“乐观”的幻想中醒来转而拥抱“悲观”的现实Zui终解决库存超扣难题的。

初期的美好设想：乐观锁与重试机制

Zui初，品类层库存扣减采用 乐观锁 机制。这听起来hen美好，不是吗？乐观锁有点像是一位比较乐观的人，总是会假设Zui好的情况，在要出现问题之前快速解决问题。它的核心思想hen清晰——并发扣减时版本号冲突，重试即可。

在代码层面我们通过 `@Version` 注解标记版本号字段，配合自定义的 `@OptimisticLockRetry` 注解实现冲突重试。思路hen清晰：假设冲突hen少发生，通过版本号校验实现并发控制。核心思路提前加锁防冲突和事后校验避冲突，对应的就是悲观锁和乐观锁技术。

这种方案乐观锁相比悲观锁来说不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性Neng上往往会geng胜一筹。我们以为物资管理系统的并发量有限，这种“先修改再验证”的策略足够了。

当理想撞上现实：快照隔离的陷阱

但实际测试中发现：重试永远读到旧数据，版本号永远冲突，Zui终抛出异常。 这简直让人抓狂！明明代码里写了重试逻辑，为什么还是报错？

经过一番痛苦的排查，根因终于浮出水面：数据库的隔离级别。本项目使用 PostgreSQL，默认隔离级别为 `READ COMMITTED`，但在大事务中Ru果内层方法以默认的 `REQUIRED` 传播方式加入外层事务，整个事务共享同一个快照。

这就形成了一个大事务套小事务的结构——外层事务管理借用流程，内层事务负责库存扣减。两层操作必须在同一事务内完成，否则会出现库存数与单品状态不一致的情况。geng关键的是当外层事务Yi经对目标行Zuo过读取后内层重试读取到的仍然是事务开启时的快照数据，而非其他事务Yi提交的Zui新值。

这意味着：乐观锁检测到冲突后重试，但重试读到的还是同一份旧快照，版本号自然还是冲突的。重试变成了死循环。这就像你在照镜子，镜子里的你永远比现实慢半拍，无论你怎么努力追赶，kan到的dou是过去的影像。

探索歧路：那些被否决的方案

在意识到乐观锁行不通后我们也尝试过其他“高大上”的方案，但Zui终dou因为各种原因放弃了。

方案一：异步解耦

有人提议将库存扣减改为异步事件通知，解耦借用流程与库存操作。这听起来hen符合微服务架构的理念。

但仔细一想，问题接踵而至：需要引入消息队列、死信队列、消费幂等处理，架构复杂度大幅提升，属于杀鸡用牛刀。而且，外层事务回滚时内层事务Yi经提交，库存扣减不会回滚。需要引入补偿机制，复杂度骤增，对于一个毕设项目来说过于笨重。

方案二：独立事务

另一个思路是让库存扣减以独立事务运行，每次重试douNeng读到Zui新提交的数据。

然而问题依然存在：外层事务回滚时内层事务Yi经提交，库存扣减不会回滚。需要引入补偿机制，复杂度骤增，对于一个毕设项目来说过于笨重。这种方案虽然解决了快照读的问题，却引入了数据一致性的geng大隐患。

回归本源：悲观锁的务实选择

既然“高级”的方案dou不合适，我们决定回归Zui原始、Zui朴实的方法——悲观锁。

众所周知，高并发情况下对于库存的操作要格外小心，处理不当可Neng导致库存超扣，带来不必要的损失。悲观锁认为要超扣，提前防止。悲观锁顾名思义，就是hen悲观，每次去拿数据的时候dou认为别人会修改，所以每次在拿数据的时候dou会上锁，这样别人想拿这个数据就会 block 直到它拿到锁。

相对悲观锁而言，乐观锁假设认为数据一般情况下不会产生并发冲突，所以在数据进行提交geng新的时候，才会正式对数据是否产生并发冲突进行检测。但在我们的 SICS 系统中，这种假设显然不成立。

Zui终选择方案三。对于一个并发量有限的物资管理系统，悲观锁是Zui务实的选择。悲观锁虽然kan起来"不够优雅"，但它与事务模型的契合是天然的：加锁读取本身就是事务的一部分，不存在快照失效的问题。技术选型不应该追求"高级"，而应该追求"合适"。

代码层面的改造

改造过程其实并不复杂。在 `ItemMapper` 中新增悲观锁查询方法：

@Select
Item selectByIdForUpdate Long id);

接着，将 `ItemServiceImpl` 中所有库存写操作的 `selectById` 替换为 `selectByIdForUpdate`，同时移除所有 `@OptimisticLockRetry` 注解。

在读取 Item 行时直接加 `SELECT ... FOR UPDATE`，其他事务等待行锁释放后再操作。下面是悲观锁的代码，加锁和解锁dou是需要消耗CPU资源的，所以在订单并发少的情况使用乐观锁会是一个geng好的选择。但此处考虑订单并发问题，我们选择了悲观锁。

这种改变带来的效果是立竿见影的。虽然悲观锁它保证了数据的绝对一致性，而且代码逻辑变得异常清晰，不再有那些令人头晕的重试机制。

进阶优化：SKIP LOCKED 与索引的艺术

解决了品类层的库存扣减，我们还要面对单品层的锁定策略。单品层的锁定策略本身没有问题——`FOR UPDATE SKIP LOCKED` 是处理此类场景的Zui佳实践。

在处理单品借用时我们需要找到指定品类下状态为"在库"的单品，按批次和创建时间排序，加行锁，跳过Yi被其他事务锁定的行。这天然避免了并发借用同一批单品时的等待和死锁。

使用 SKIP LOCKED 避免排队

我们使用了类似这样的 SQL 逻辑：

wrapper.eq;
wrapper.eq;
wrapper.orderByAsc;
wrapper.orderByAsc;
wrapper.last;

它的语义是：找到指定品类下状态为"在库"的单品，按批次和创建时间排序，加行锁，跳过Yi被其他事务锁定的行。这就像在排队买票，Ru果前面的窗口正在处理，你就自动跳到下一个空闲窗口，而不是傻傻地等着。

索引的重要性：避免锁升级

但是`FOR UPDATE SKIP LOCKED` 虽然只锁匹配的行，但Ru果 `WHERE item_id = ? AND status = 'IN_STOCK'` 没有合适的索引，PostgreSQL 不得不扫描全表来定位目标行，途中遇到的每一行dou会被加上行锁——即使Zui终不需要这些行。这会导致锁升级，严重影响性Neng。

为避免锁升级，需要创建一个覆盖查询条件的复合索引：

CREATE INDEX idx_item_individual_borrowable
ON item_individual;
COMMENT ON INDEX idx_item_individual_borrowable IS
'借用分配查询索引：按品类+在库状态定位可借单品，按批次和创建时间排序，覆盖 FOR UPDATE SKIP LOCKED 查询避免锁升级';

索引列的设计遵循以下原则：这样查询Ke以直接走索引定位 + 索引有序返回，不需要回表，也不会在扫描过程中锁定无关行。`updateBatchByIds` 中的 `version = version + 1` 也顺带保留了行级变geng审计Neng力。

并发测试：验证锁的有效性

为了验证我们的改造是否有效，我们进行了残酷的并发测试。

众所周知，高并发情况下对于库存的操作要格外小心。我们模拟了两种情况：

第一种情况：Python爬虫请求并发测试，一次发送6个请求访问同一个接口。在这种高频率的冲击下Ru果没有锁，库存瞬间就会变成负数。

第二种情况：手动测试同时刷新两个窗口，添加休眠。代码逻辑大概如下：

$user = User::lockForUpdate->first;
sleep;

第一个页面加载完成5秒后第二个页面加载完成。说明进行了阻塞。锁起作用了。但是请求非常频繁的情况下为什么不起作用了？第二种情况发生了阻塞，没有出现 count 字段出现负数的情况，是不是因为不同窗口的问题。第一种情况相当于，刷新同...

通过测试我们发现，在引入悲观锁和正确的索引后即使在第一种高并发爬虫测试的情况下系统也Neng稳定运行，没有出现库存超扣的情况。访问量不大，不会造成压力时使用悲观锁，面对高并发的情况下我们应该使用乐观锁——这句话在特定的隔离级别和事务模型下并不完全准确。在我们的 SICS 系统中，悲观锁 + `FOR UPDATE SKIP LOCKED` + 合适的索引，Yi经足够应对并发场景，且代码清晰、易于维护。

与反思

这次从乐观锁到悲观锁的转型，让我对并发控制有了geng深的理解。乐观锁不Neng解决脏读的问题，而且在特定的事务隔离级别下重试机制可Neng会失效。

悲观锁虽然kan起来传统，但在处理库存增减问题上，利用悲观锁Ke以有效的防止减库存问题。传统的关系型数据库里边就用到了hen多这种锁机制，比如行锁，表锁等，读锁，写锁等，dou是在Zuo操作之前先上锁。

对于一个小型管理系统而言，这不是妥协，而是取舍。我们不需要为了应对双十一级别的流量而把系统搞得无比复杂。简单、可靠、易于维护，才是毕设项目，甚至hen多企业级项目Zui应该追求的目标。

Zui后我想说技术没有银弹。不要迷信网上的“Zui佳实践”，一定要结合自己的业务场景和数据模型进行分析。就像这次排查，Ru果我没有深入去研究事务的快照隔离机制，可Neng永远也找不到乐观锁失效的真正原因，只Neng在迷茫中不断重试。

---