synchronized 与 CAS：一个先排队再干活，一个先干活、失败了再来

• “读、判断、写回”是三步，任何两步之间都可能换另一个线程上来（上下文切换），或者两个核真的同时在跑。
• volatile 只保证每次读都是最新的，不保证三步连在一起（JMM 下一圈坑 4）。
• 缺的那一块：让“检查”和“修改”成为一个整体。要么让别的线程在外面等（锁），要么让修改在“检查结果还成立”时才生效、否则重来（CAS）。

不懂这一点时的典型误用：每次调用都 synchronized (new Object())，或者锁一个 Integer 库存值。前者每个线程锁的是自己新建的对象，等于没锁；后者库存一变，锁的就是另一个对象了（⑥ 坑 1）。

选择规则：先看数据在哪：多台机器共享就交给数据库或 Redis；只在一个 JVM 里，只改一个数就用原子类，改好几样就用 synchronized，要超时或可中断再换 ReentrantLock。本页学 synchronized 和 CAS 原子类，ReentrantLock 见 AQS 页。

④-1对象头：每个对象开头 8 个字节的 mark word

④-2编译之后：同步块是一对指令，同步方法只是一个标志

 6: monitorenter                  // 拿锁
 7: … if (left < 1) …
16: aload_1
17: monitorexit                   // return 0 前放锁
18: ireturn
19: … left--
31: monitorexit                   // return 1 前放锁
32: ireturn
33: astore_2                      // 中间抛了异常：
35: monitorexit                   // 先放锁
37: athrow                        // 再接着抛
Exception table:
   from    to  target type
     7    18    33   any
    19    32    33   any

synchronized int takeMethod();
  flags: (0x0020) ACC_SYNCHRONIZED
  Code: … 没有 monitorenter / monitorexit

④-3锁升级：一步一步看对象头和 ObjectMonitor

一个库存对象 stock，main、exec-17、exec-23 三个线程轮流对它加锁。每一步的对象头取自 JOL 实测。打开右上角的开关，换成 JDK 17 加 -XX:+UseBiasedLocking 的版本。

• 1轻量级锁就是一次 CAS。线程在自己的栈帧里放一个“锁记录”，把对象头原样复制进去，再用 CAS 把对象头换成指向这个锁记录的指针。放锁时 CAS 换回来。没人抢的锁，加一次放一次，两次 CAS。
• 2CAS 失败说明有人抢，就膨胀成重量级锁。JVM 分配一个 ObjectMonitor，对象头改成指向它。抢不到的线程先自旋一会儿（适应性自旋：上次自旋成功过，这次就多转几圈），还不行就进入口队列 park，这就是 BLOCKED。
• 3wait / notify 只能用在重量级锁上。持锁线程调 wait()：放开 monitor，进 WaitSet，状态 WAITING；别人 notify() 只是把它从 WaitSet 挪到入口队列，要等通知的那个线程放锁、再抢到锁，wait() 才返回。
• 4实测 两个线程都走了，对象头还是 fat lock：ObjectMonitor 不会立刻拆掉，由后台的 MonitorDeflationThread 过一阵子统一回收（JDK 15 起）。

④-4CAS 和原子类：不排队，提交时核对

• 1ABA：CAS 只比较值。订单状态 PAID → REFUNDING → PAID，值回到了原样，CAS 看不出中间变过。实测 AtomicReference 照样把它改成了 SHIPPED；AtomicStampedReference 带一个版本号，版本从 0 变成了 2，CAS 被拒绝。数值累加不怕 ABA，状态机和无锁链表才怕。
• 2LongAdder：一个 base 加一组 Cell。没冲突时 CAS 加到 base；冲突了，每个线程按自己的探针值挑一个 Cell 去加，sum() 时再把所有格子加起来。写快、读慢、读到的不是某一瞬间的精确快照。

④-5为什么这样设计：大多数锁根本没人抢

决定胜负的约束：实测下来，绝大多数被加锁的对象只被一个线程用过（HotSpot 团队的统计，也是偏向锁当年的依据）。所以快路径要尽量便宜，慢路径才付代价。偏向锁把“没人抢”再往下压到连 CAS 都不用，但现代 CPU 的 CAS 已经很便宜，撤销偏向又要停在安全点，JDK 15 起默认关掉（JEP 374），JDK 18 起参数作废。

private final Object stockLock = new Object();       // 私有、final、专门用来当锁
synchronized (stockLock) { if (left < 1) return false; left--; }
synchronized (stockLock) { while (!paid) stockLock.wait(); }   // 等条件：一定写在 while 里
synchronized (stockLock) { paid = true; stockLock.notifyAll(); }

AtomicInteger left = new AtomicInteger(100);
left.decrementAndGet();                              // 一步完成，不会失败
left.compareAndSet(cur, cur - 1);                    // 自己写“检查 + 修改”时用
left.updateAndGet(v -> v > 0 ? v - 1 : v);           // 带判断的更新，内部就是 CAS 循环
LongAdder sold = new LongAdder(); sold.increment(); sold.sum();
AtomicStampedReference<String> st = new AtomicStampedReference<>("PAID", 0);

锁粗化、锁消除、偏向锁的历史、monitor 回收、JDK 21 以后的新加锁方式，这些放到第⑥步。

$ java -cp … MarkWord        （JDK 17 默认）
1. 刚 new 出来       0x…0001 (non-biasable)
2. main 拿着锁       0x0000fe80e872e1e0 (thin lock)
3. 放开锁以后         0x…0001 (non-biasable)
4. exec-17 拿着锁，exec-23 等（BLOCKED）
                     0x0000fe8098001502 (fat lock)
5. 两个都走了         0x0000fe8098001502 (fat lock)
6. 算过 identityHashCode
                     0x0000004b4523f801 (hash: 0x4b4523f8)
7. 再对它加锁         0x0000fe80e872e1e0 (thin lock)

$ java -XX:+UseBiasedLocking \
       -XX:BiasedLockingStartupDelay=0 -cp … MarkWord
1. 刚 new 出来       0x…0005 (biasable)
2. main 拿着锁       0x0000f98fe4017805
                     (biased: 0x…3e63f9005e; epoch: 0)
3. 放开锁以后         同上，还偏向 main
4. exec-17 拿着锁，exec-23 等（BLOCKED）
                     0x0000f98f98001502 (fat lock)
5. 两个都走了         (fat lock)
6. 算过 identityHashCode
                     0x0000001f28c15201 (hash: …)
7. 再对它加锁         (thin lock，不再偏向)

• 1默认模式：没人抢时是 thin lock，地址 0x0000fe80e872e1e0 是 main 线程栈上的锁记录；放锁后对象头原样还原。偏向模式：放锁后对象头不变，还写着 main，下次 main 再来连 CAS 都不用。
• 2第 6、7 步：算过 identityHashCode，哈希值占了对象头，偏向模式下这个对象也不能再偏向，加锁直接走 thin lock。

$ java -cp … Aba
AtomicReference：       CAS(PAID → SHIPPED) = true，现在 SHIPPED（中间被退款过，它看不出来）
AtomicStampedReference：CAS(PAID@0 → SHIPPED) = false，现在 PAID@2（版本号变了，拒绝）

五种写法的吞吐：同一个计数，1 / 2 / 4 个线程

实测 单位：百万次/秒。2 核 ARM，JDK 17，每格 2000 万次、3 轮取最快，加了 -XX:-EliminateLocks（关掉锁粗化，见 ⑥ 第三圈）。普通 main 程序，不是 JMH；4 个线程有时比 2 个线程快，是因为 2 核上 4 个线程有一半时间在轮流跑、反而撞得少，这类数字只看量级。

• 1没人抢时（1 线程）：synchronized 每秒 5900 万次，一次约 17 纳秒；“synchronized 很重”在单线程下不成立。
• 2有人抢时：原子类和 LongAdder 比两种锁快 2.5～15 倍；手写的 CAS 循环却和锁差不多慢，因为大量失败重试，每次失败还要把缓存行从另一个核抢回来。能用 incrementAndGet、addAndGet 这类一步完成的方法，就别自己写循环。
• 3全景第 7 站 CAS 重试 0 次，是因为那里的 CAS 夹在 HTTP 请求和数据库调用之间，两个线程几乎碰不上；这里是两个线程不停地对同一个地址做 CAS，冲突密集。

• HotSpot 源码：ObjectSynchronizer::enter、ObjectMonitor::enter 的自旋和入队，cxq 和 EntryList 两条队
• JDK 21 的 -XX:LockingMode=2：线程锁栈怎么取代栈上锁记录，用 JOL 看对象头的差别
• JMH 正式测：锁粗化、偏向锁、LongAdder 在多核机器上的曲线
• VarHandle：比原子类更底层的 CAS 和各种内存序（JMM 页第三圈）
• AQS：ReentrantLock 怎么用 CAS 加一个队列搭出来（J02 下一个知识点，已有页）

自测