快手二面：乐观锁是怎么用它来处理多线程问题的？

文章内容收录到个人网站，方便阅读：http://hardyfish.top/

乐观锁不加互斥锁阻塞线程，而是让线程先读数据并计算，提交写入时检查版本是否被别人改过。
如果被改过就失败并重试/放弃，核心是检测冲突而不是预防冲突。

适用：读多写少、冲突概率低的场景（热点不高）。
不适用：高冲突时会出现重试风暴。

内存并发（Java 层）：CAS/原子类/StampedLock

方案 A1：CAS 原子类（Atomic）

AtomicInteger stock = new AtomicInteger(100);

boolean decOnce(int n) {
    while (true) {
        int cur = stock.get();
        if (cur < n) return false;       // 不够则失败
        if (stock.compareAndSet(cur, cur - n)) { // CAS 成功表示没人改过
            return true;
        }
        // CAS 失败：有人改过，重试（可加退避）
    }
}

要点：

**比较并交换（CAS）**是硬件指令，失败重试即可。
高并发下加指数退避或限制最大重试次数，避免 CPU 自旋打满。

方案 A2：解决 ABA： AtomicStampedReference

当值可能 A→B→A 时，单纯比较值会误判没人改过（ABA 问题），用值+版本戳：

AtomicStampedReference<Integer> ref = new AtomicStampedReference<>(100, 0);

boolean dec(int n) {
    while (true) {
        int[] stamp = new int[1];
        int cur = ref.get(stamp);
        if (cur < n) return false;
        int newStamp = stamp[0] + 1;
        if (ref.compareAndSet(cur, cur - n, stamp[0], newStamp)) return true;
    }
}

方案 A3：读多写少下的乐观读：StampedLock

StampedLock lock = new StampedLock();
long stamp = lock.tryOptimisticRead();
int xLocal = x;           // 无锁读取
if (!lock.validate(stamp)) {         // 期间若被写，验证失败
    stamp = lock.readLock();         // 再走读锁兜底
    try { xLocal = x; } finally { lock.unlockRead(stamp); }
}

要点：乐观读→验证→必要时回退到读锁，减少阻塞。

数据库并发（MySQL/Oracle 等）：版本号/条件更新

标准两步：先读出 version，更新时携带 WHERE version=?，受影响行数=1 视为成功，否则重试。

表结构

ALTER TABLE product ADD COLUMN version INT NOT NULL DEFAULT 0;

更新 SQL

-- 假设要扣减库存 1
UPDATE product
SET stock = stock - 1,
    version = version + 1
WHERE id = #{id}
  AND stock >= 1              -- 业务约束
  AND version = #{oldVersion};

Java 伪代码（MyBatis/JdbcTemplate）

Product p = dao.selectForUpdateLikeNoLock(id); // 普通查询即可（不要 FOR UPDATE）
int retry = 0, maxRetry = 5;
while (retry++ < maxRetry) {
    int rows = dao.updateStockWithVersion(id, p.getVersion());
    if (rows == 1) return true;           // 成功
    p = dao.selectById(id);               // 别人改过，拿新版本再试
}
return false;                              // 超过重试上限，交给上层处理/排队

要点：

不需要悲观锁/行锁；靠版本冲突检测避免丢失更新。
冲突时重读最新数据再尝试，或直接失败给调用方。
JPA 可用 @Version 自动完成（抛 OptimisticLockException 后应用层重试）。

扩展：不用显式 version 字段时，也可用业务条件做条件更新：
WHERE amount = #{oldAmount} 或 WHERE updated_at = #{oldTs}，效果类似但不如版本号稳妥。

分布式场景（跨进程）：Redis/WATCH 或 Lua

方案 C1：Redis WATCH/MULTI/EXEC（CAS 语义）

WATCH stock:sku1        # 监视键
val = GET stock:sku1
if val >= n:
  MULTI
  DECRBY stock:sku1 n   # 事务块
  EXEC                  # 若期间有人改过，EXEC 返回空，表示失败需重试
else:
  UNWATCH

要点：轻量 CAS，适合低，中冲突，高冲突会频繁失败重试。

方案 C2：Redis Lua 脚本（原子性+业务校验）

-- KEYS[1]=stockKey, ARGV[1]=n
local cur = tonumber(redis.call('GET', KEYS[1]) or '0')
if cur >= tonumber(ARGV[1]) then
  redis.call('DECRBY', KEYS[1], ARGV[1])
  return 1
else
  return 0
end