reentrantreadwritelock通过threadlocal+holdcounter实现线程级可重入读锁，写锁复用aqs的exclusiveownerthread；读锁不可升级为写锁，否则死锁；unlock()必须由持锁线程调用，否则抛illegalmonitorstateexception。
ReentrantReadWriteLock 怎么判断当前线程是否已持锁
它靠的是 ThreadLocal + 内部 HoldCounter 结构。每个线程在首次获取读锁时，会在自己的 ThreadLocal 里存一个 HoldCounter 实例，记录该线程重入次数；写锁则直接复用 AQS 的 exclusiveOwnerThread 字段。
所以「可重入」不是靠全局计数，而是线程粒度的：同一线程反复调用 readLock().lock() 不会阻塞，但其他线程想抢读锁，得等所有持有读锁的线程都释放完（注意：不是等「读锁总数」归零，而是等「持有读锁的线程集合」全部退出）。
- 写锁重入时，
getWriteHoldCount()返回当前线程的写锁嵌套深度 - 读锁重入时，
getReadHoldCount()返回当前线程的读锁嵌套深度，不是全局读锁数 - 调用
getQueueLength()看等待线程数，但这个值不区分读/写等待者，容易误判竞争激烈程度
为什么 unlock() 必须和 lock() 在同一线程调用
因为 ReentrantReadWriteLock 的释放逻辑严格校验线程身份：读锁 unlock() 会先查自己 ThreadLocal 里的 HoldCounter，写锁 unlock() 则比对 exclusiveOwnerThread == Thread.currentThread()。一旦不匹配，直接抛 IllegalMonitorStateException。
常见错误场景是：在异步回调、线程池任务或 ForkJoinTask 里获取锁，却试图在另一个线程释放 —— 这不是“锁没释放”，而是根本没资格释放。
- 不要把
ReentrantReadWriteLock当成普通对象传给其他线程后调用unlock() - 使用
tryLock(long, TimeUnit)时，超时返回false后别忘了检查是否已持锁，避免重复unlock() -
newCondition()只能从写锁获取，读锁调用会抛UnsupportedOperationException
读锁升级为写锁为什么一定会死锁
不是语法禁止，而是逻辑上不可能安全完成：当前线程持着读锁，意味着其他线程可能也持着读锁；此时若它再去 acquire 写锁，就得等所有读锁释放 —— 包括它自己持有的那份。但它不释放读锁，就卡在写锁请求上；不拿到写锁，又无法释放读锁。典型的自旋等待。
ReentrantReadWriteLock 没有提供「降级」以外的锁转换机制。官方只允许写锁 → 读锁（降级），且必须在写锁未释放前完成。
- 试图先
readLock.lock()再writeLock.lock()：必然阻塞，且不可中断（除非超时） - 正确做法是：预判需要写，直接用
writeLock()；或先用写锁，后续降级为读锁以便共享访问 - 降级示例：
writeLock.lock(); /* ... */ readLock.lock(); writeLock.unlock(); // 此时读锁仍有效
StampedLock 和 ReentrantReadWriteLock 的关键区别在哪
核心差异不在性能，而在语义模型：ReentrantReadWriteLock 是悲观锁，靠阻塞实现互斥；StampedLock 是乐观读 + 悲观 fallback，用版本戳（stamp）做无锁快路径判断。
这意味着：如果读多写少且读操作极轻量，StampedLock 的乐观读几乎不加锁；但一旦检测到写发生，就得退回到慢路径重新读 —— 这个「重试成本」容易被忽略。而 ReentrantReadWriteLock 读锁虽重，但行为确定、可预测。
-
StampedLock不可重入，也不支持条件变量（newCondition()） -
tryOptimisticRead()返回的 stamp 为 0 表示当前无法乐观读，需改走readLock() - 使用
validate(stamp)必须在读操作**结束后立即**调用，中间不能有修改共享状态的逻辑，否则校验失效
真正难的从来不是选哪个锁，而是想清楚：你的读操作是否允许「看到中间态」？是否接受重试？有没有线程会一边读一边长期阻塞写？这些才是决定用哪种锁的关键。
