手写实现男用贞操锁时踩过的3个致命坑

报错堆满屏幕，StackTrace 长得像天书，新手直接懵圈。

别慌，这很正常。很多开发者在尝试 手写实现 类似 男用贞操锁 这种高并发、强一致性状态机时，都会遇到这种“代码跑起来了，但逻辑全乱了”的噩梦。

我当年在重构一个分布式库存扣减系统时，就栽在了这个坑里。当时为了追求极致性能，没直接用 Redis 锁，而是自己 手写实现 了一套基于数据库乐观锁的方案。结果上线第一天，超卖严重，报警电话被打爆。

今天就把我踩过的这些坑，掰开了揉碎了讲给你听。咱们不整虚的，直接上干货，看看怎么避坑，怎么写出既安全又高效的代码。

现象：状态混乱与并发冲突

先看最典型的报错现象。

你运行测试用例，单线程跑没问题。一旦上多线程，控制台就开始刷 OptimisticLockException 或者 DataIntegrityViolationException。

更隐蔽的问题是：状态不同步。比如，A 用户发起了“上锁”请求，B 用户几乎同时发起了“解锁”请求。按照业务逻辑，只有“上锁”状态才能被“解锁”。但在高并发下，你发现 B 用户的请求竟然成功了，导致系统状态变成了一个既没锁也没解锁的“薛定谔状态”。

这时候看 StackTrace，你会发现报错点往往在 UPDATE 语句执行之后，而不是之前。这让人非常困惑：明明加了事务，为什么还会脏读？

根源：CAS 失效与中间态暴露

问题的根本原因，在于对 手写实现 中的“比较并交换”（Compare-And-Swap, CAS）操作理解不够深，以及数据库隔离级别的默认行为。

很多新手写代码时，习惯这样：

SELECT 当前状态。
在内存中判断状态是否符合预期。
UPDATE 数据库，把状态改成新值。

这就出了大问题。步骤 1 和步骤 3 之间，存在一个时间窗口。如果两个线程同时读取了相同的旧状态，都判断为“符合预期”，然后都去执行 UPDATE，那么后执行的线程会覆盖先执行线程的结果，或者导致逻辑错误。

这就是典型的 Race Condition（竞态条件）。在 男用贞操锁 这种场景中，状态流转是严格线性的：未锁定 -> 锁定中 -> 已解锁。任何跳跃或覆盖都是致命的。

此外，MySQL 默认的 REPEATABLE READ 隔离级别下，SELECT 不加 FOR UPDATE 是快照读。你读到的状态，可能是几毫秒前的旧值，而不是最新的实时值。这就是为什么你明明加了事务，却还是读到了脏数据。

对比：错误写法 vs 正确写法

咱们直接上代码对比。以 Java + Spring Boot + MyBatis 为例。

错误写法：先查后改

// 错误示范：典型的 Race Condition
public void toggleLockState(Long userId, int targetState) {// 1. 查询当前状态LockRecord record = lockMapper.selectById(userId);// 2. 内存判断if (record.getState() == targetState) {// 3. 直接更新，没有校验原状态record.setState(newState);lockMapper.updateById(record);}
}

这段代码看似逻辑通顺，但在并发下必炸。因为 selectById 和 updateById 不是原子操作。

正确写法：CAS 原子更新

正确的 手写实现 必须利用数据库的行锁特性，将“判断”和“更新”合并到一条 SQL 语句中。

// 正确示范：CAS 原子操作
public int toggleLockState(Long userId, int expectedState, int newState) {// 一条 SQL 完成判断和更新// WHERE 条件里包含了状态校验// 如果状态不匹配，影响行数为 0return lockMapper.casUpdate(userId, expectedState, newState);
}

对应的 MyBatis XML 或注解：

UPDATE lock_table 
SET state = #{newState}, version = version + 1, update_time = NOW()
WHERE user_id = #{userId} AND state = #{expectedState}

关键点：

原子性：UPDATE 语句本身在数据库层面是原子的。
条件更新：WHERE 子句里必须带上 state = #{expectedState}。
版本号：加上 version 字段，每次更新 +1，这是乐观锁的标准做法。

如果影响行数为 0，说明状态已经被其他线程修改了，此时应该抛出异常或进行重试，而不是直接忽略。

复现与修复：完整代码实战

为了让你彻底理解，这里给出一套完整的 手写实现 代码，包含实体类、Mapper、Service 和 Controller。

1. 实体类 LockRecord

@Data
public class LockRecord {private Long id;private Long userId;private Integer state; // 0: 未锁定, 1: 锁定中, 2: 已解锁private Integer version;private LocalDateTime updateTime;
}

2. Mapper 接口与 XML

@Mapper
public interface LockMapper {LockRecord selectById(Long userId);// CAS 更新方法int casUpdate(@Param("userId") Long userId, @Param("expectedState") int expectedState, @Param("newState") int newState);
}

<!-- LockMapper.xml -->
<update id="casUpdate">UPDATE lock_tableSET state = #{newState},version = version + 1,update_time = NOW()WHERE user_id = #{userId}AND state = #{expectedState}
</update>

3. Service 层逻辑

这里有一个进阶技巧：重试机制。

在高并发下，CAS 失败是常态。如果直接报错，用户体验很差。我们可以加入简单的重试逻辑。

@Service
public class LockService {@Autowiredprivate LockMapper lockMapper;private static final int MAX_RETRIES = 3;public boolean lock(Long userId) {for (int i = 0; i < MAX_RETRIES; i++) {// 1. 查询当前状态LockRecord record = lockMapper.selectById(userId);if (record == null) {throw new BusinessException("用户记录不存在");}// 2. 判断是否可锁定if (record.getState() != 0) {return false; // 已经锁定或已解锁，不能再次锁定}// 3. 尝试 CAS 更新为锁定状态int rows = lockMapper.casUpdate(userId, 0, 1);if (rows > 0) {return true; // 锁定成功}// 4. 失败，休眠一小段时间后重试try {Thread.sleep(50);} catch (InterruptedException e) {Thread.currentThread().interrupt();}}return false; // 重试多次后仍失败}
}

4. 单元测试复现

用 JUnit 5 写一个并发测试，验证我们的实现是否真的防住了竞态条件。

@Test
public void testConcurrentLock() throws InterruptedException {Long userId = 1001L;// 初始化状态为未锁定lockMapper.insert(new LockRecord(userId, 0, 0));ExecutorService executor = Executors.newFixedThreadPool(10);CountDownLatch latch = new CountDownLatch(10);AtomicInteger successCount = new AtomicInteger(0);for (int i = 0; i < 10; i++) {executor.submit(() -> {try {boolean locked = lockService.lock(userId);if (locked) {successCount.incrementAndGet();}} finally {latch.countDown();}});}latch.await();executor.shutdown();// 断言：只有 1 个线程能成功锁定assertEquals(1, successCount.get(), "应该只有一个线程成功锁定");// 断言：数据库状态确实是锁定LockRecord record = lockMapper.selectById(userId);assertEquals(1, record.getState());assertEquals(1, record.getVersion());
}

运行这个测试，如果你用的还是之前的“先查后改”写法，successCount 可能会大于 1，且 version 可能只增加了 1，但状态却是错的。用了 CAS 写法，测试必然通过。

规避建议与进阶技巧

除了上述核心代码，还有几个 手写实现 时的避坑建议：

不要过度依赖应用层锁：有些开发者喜欢在 Java 里用 synchronized 或 ReentrantLock。这在单机环境下没问题，但一旦部署多实例，应用层锁就失效了。男用贞操锁 这种涉及资金或关键状态的操作，必须依赖分布式锁或数据库原子操作。
日志要详细：在 CAS 失败时，打印出 userId、expectedState、actualState（从 DB 重新查的）。这样线上排查问题时，你能一眼看出是哪个线程抢占了资源。
考虑使用 Redis 分布式锁：如果并发量极大（QPS > 1000），数据库锁可能会成为瓶颈。此时可以考虑用 Redis 的 SETNX 或 Redisson 客户端实现分布式锁。但注意，Redis 锁也有过期时间问题，需要处理看门狗（Watchdog）机制。
参考权威资料：我在实现过程中，参考了 Stack Overflow 上关于 "Optimistic Locking in JPA" 的高票回答，以及 MySQL 官方文档中关于 InnoDB 行锁机制的说明。这些资料对理解底层原理非常有帮助。特别是 SO 上有个大神解释得特别好：“Don't trust the application layer, trust the database atomicity.”（不要信任应用层，要信任数据库的原子性）。
避免长事务：虽然我们要用事务保证一致性，但事务范围要尽可能小。不要在一个事务里做查询、计算、更新、发送消息等操作。只做核心的 CAS 更新，其他逻辑放在事务外。