AQS 下一圈：读多写少该用哪把锁，锁竞争怎么从线上抓出来

• 读也要排队。只用 ReentrantLock 或 synchronized，一千个查库存的线程也只能一个一个进；明明谁都没改数据，却在互相等。
• 下游没人护着。线程池有 200 个线程，库存服务只扛得住几个并发，所有线程一起涌过去，它一慢，200 个线程全卡在它身上（全景第 2 站的池子被占满）。
• 线程转储只是一张照片。jstack 拍到的是那一瞬间：碰巧拍到几个 BLOCKED，不知道它们已经等了多久、一分钟里一共等了多少次、是不是每次都卡在同一把锁上。拍得不巧，问题就漏过去了。
• 缺的那一块：按读写区分的锁、按名额放行的闸门，和一台一直开着的“录像机”。前两个都是 AQS 换个用法；录像机是 JDK 自带的 JFR。

不懂这一点时的典型误用：觉得“读多写少就上读写锁”是常识，把 ReentrantLock 换成 ReentrantReadWriteLock，再顺手传个 true 要公平。本机实测吞吐从每秒 1515 万次读掉到 20 万次（⑤）。

选择规则：读多写少先问能不能做成不可变快照；不能，再拿实测比 ReentrantLock、读写锁、StampedLock，别凭直觉。护下游用 Semaphore 管并发，用限流器管 QPS。找锁竞争：先开 JFR 录一段，再用 jstack 看现场。本页学读写锁、StampedLock、Semaphore 和 JFR 的锁事件。

④-1ReentrantReadWriteLock：一个 int 劈成两半

• 1写锁会不会被读锁饿死？非公平模式下，新来的读线程只有在“队首等着的是一个写线程”时才让一让（源码里的 readerShouldBlock() 调 apparentlyFirstQueuedIsExclusive()，注释原话是“避免写线程无限饥饿的一个启发式办法，只在概率上有效”）。所以一般不会饿死，但写线程等的时间会被一串读拉长。实测 写线程等锁最久 10.0～10.6 ms，比 ReentrantLock 的 6.9～7.4 ms 长。
• 2公平模式：读线程只要看到前面有人排队（hasQueuedPredecessors()）就去排队。高并发下几乎每次加锁都要进队列、park、被叫醒，交接一次就是几微秒的上下文切换。
• 3锁降级可以，升级不行。拿着写锁再拿读锁，然后放写锁，可以（降级）；拿着读锁去拿写锁，要等所有读锁都放掉，而自己就拿着一个，于是永远等下去（⑥ 坑 4）。

④-2StampedLock：乐观读什么都不写

④-3Semaphore：state 是剩下几个名额

• 1new Semaphore(3) 把 AQS 的 state 设成 3。acquire() 是 AQS 的共享模式：CAS 把 state 减一，减不下去（已经是 0）就排队 park；release() 加一，再叫醒排队的。和 ReentrantLock 不一样，它不记“谁拿了”，任何线程都能 release。
• 2拿它护住下游，叫舱壁（bulkhead）：调库存服务前先拿一个名额，名额用完就等一会儿，等不到就降级（返回“稍后再试”或读缓存）。这样库存服务最多同时被 3 个线程调用，它慢了也只卡住这 3 个，线程池里其他 197 个照样干别的。
• 3它限的是同时进行的个数，不是每秒次数。调用 30 ms 的服务、3 个名额，大约每秒能过 100 次；调用变成 300 ms，就只剩每秒 10 次。要按 QPS 限，用令牌桶（J12）。

④-4JFR：JVM 自带的录像机

• 1阈值：JDK 自带的 default.jfc 是 20 ms，profile.jfc 是 10 ms（本页用 profile）。短于阈值的等待不记，所以 JFR 抓的是“等得久的”，不是“所有的”。
• 2怎么开：启动时加 -XX:StartFlightRecording:filename=x.jfr,settings=profile；已经在跑的进程用 jcmd <pid> JFR.start、JFR.dump。看：jfr summary、jfr print --events …，或者用 JDK Mission Control 打开。官方说 default 配置开销通常在 1% 以内，所以很多团队生产上一直开着、出事了 dump 最近一段。

④-5为什么这样设计：读锁要不要“写一下”

决定胜负的约束：读的临界区有多长，和写有多频繁。读很短时，CAS 共享计数的开销盖过了“读能并行”的好处，读写锁反而输给普通锁；读很长、写很少时，读写锁才赚。乐观读把读的开销降到几乎为零，代价是写法变难，所以 JDK 把它做成一个单独的类，而不是改掉读写锁。

ReentrantReadWriteLock rw = new ReentrantReadWriteLock();     // 别传 true，见坑 2
rw.readLock().lock();  try { return left; } finally { rw.readLock().unlock(); }
rw.writeLock().lock(); try { left--; }      finally { rw.writeLock().unlock(); }

StampedLock sl = new StampedLock();
long st = sl.tryOptimisticRead();
long a = left, b = sold;                                      // 先复制到局部变量
if (!sl.validate(st)) {                                       // 被写过：退回读锁
  st = sl.readLock(); try { a = left; b = sold; } finally { sl.unlockRead(st); }
}

Semaphore permits = new Semaphore(3);
if (permits.tryAcquire(100, TimeUnit.MILLISECONDS)) {         // 拿不到就降级
  try { callInventory(); } finally { permits.release(); }     // 只有拿到了才 release
}

# JFR
java -XX:StartFlightRecording:filename=app.jfr,settings=profile …
jfr print --events jdk.JavaMonitorEnter,jdk.ThreadPark app.jfr

JFR 的阈值怎么改、synchronized 为什么只记了 7 条、各版本的 JFR 工具差别，放到第⑥步。

实验 1：库存查询读 95%、扣减写 5%，四把锁，先猜再看

• 1实测 读很短时两次运行：ReentrantLock 1515 / 1503 万次每秒，读写锁 1090 / 1052，公平读写锁 20 / 24，StampedLock 乐观读 2293 / 2328。乐观读有约 4% 核对失败、退回读锁（两次各约 184 万次）。
• 2读很长时：读写锁 47 比 ReentrantLock 42，只领先 12%。2 核上同一时刻最多两个读真正并行，写又占了 5%；核越多、读越长，读写锁的优势才越大。StampedLock 75，领先 1.8 倍。

实验 2：锁里一次 30 ms 的慢 SQL，用 JFR 录下来

$ java -XX:StartFlightRecording:filename=slow.jfr,settings=profile \
       -cp … SlowLock
synchronized 里慢 SQL：80 单用了 2413 ms（串行下限 2400 ms）
ReentrantLock 里慢 SQL：80 单用了 2409 ms
Semaphore(3) 限并发：最多同时 3 个在调库存服务，
  等 100 ms 拿不到许可被拒绝 17 次，用了 696 ms

$ jfr summary slow.jfr
 jdk.ThreadSleep          223
 jdk.ThreadPark           109
 jdk.JavaMonitorWait        8
 jdk.JavaMonitorEnter       7

$ jfr print --events jdk.JavaMonitorEnter slow.jfr
jdk.JavaMonitorEnter {
  duration = 599 ms
  monitorClass = java.lang.Object
  previousOwner = "order-exec-7"
  address = 0xE5ABF8001F80
  eventThread = "order-exec-6"
  stackTrace = [
    …SlowLock.deductStock() line: 52
    …SlowLock.lambda$main$0() line: 23
  ]
}

实测 用 jfr print --json --stack-depth 20 导出后按“事件类型 + 锁的类 + 第一个业务方法”汇总。注意 jfr print 默认只打印栈的前 5 帧，ThreadPark 的前 5 帧全是 JDK 内部，要加 --stack-depth 才看得到业务方法。

• 1不读代码就能得出结论：两把锁各让线程一共等了 8 秒多，一把是 deductStock 里的 synchronized，一把是 useCoupon 里的 ReentrantLock；Semaphore 那段每次最多等 100 ms，是设计好的。两个慢锁的总耗时都等于“80 次 × 30 ms”，说明锁里的东西是完全串行的。
• 2synchronized 只记了 7 条，ReentrantLock 记了 74 条，合计时间却差不多。原因在 ⑥ 第三圈：synchronized 放锁的线程马上又抢回来，其他线程一等就是一两秒。
• 3Semaphore(3)：80 次调用最多同时 3 个，63 次拿到名额，17 次等 100 ms 没拿到被拒绝（这些在真实系统里就走降级），总共 696 ms，没有任何线程被库存服务拖住超过 100 ms。

• 用 JFR 事件流（RecordingStream）在程序里实时统计锁等待，超过阈值就打日志或报警
• JDK Mission Control 的“锁实例”和“线程”视图，配合 jfr view（JDK 21）
• async-profiler 的 lock 和 wall 模式，看短而多的竞争（J13）
• FutureTask 为什么从 AQS 换成了自己的等待栈（上一圈列过，留给 CompletableFuture 那一页）
• 限流：令牌桶、漏桶、Sentinel 的并发线程数限流和 Semaphore 的关系（J12）

自测