ReadWriteLock 的 readLock() 调用 newCondition() 抛 UnsupportedOperationException，因读锁是共享锁，无独占等待队列，无法定义 signal 语义；写锁虽支持但极少使用，因其唤醒后仍需竞争且不解决数据状态等待本质问题。
ReadWriteLock 的 readLock() 为什么调用 newCondition() 会抛 UnsupportedOperationException
因为读锁在 JDK 实现中压根没实现条件队列逻辑，不是忘了加，是设计上就不能有。
Condition 的核心依赖是「独占模式下的等待/唤醒链表」，而读锁是共享锁——多个线程能同时持有，没法定义“谁该被 signal”：唤醒一个？全部？还是按某种顺序？JDK 不想替你做这个不可靠的决策。
-
ReentrantLock的newCondition()能用，是因为它是独占锁，等待队列天然有序 -
ReentrantReadWriteLock.ReadLock的newCondition()直接 throw new UnsupportedOperationException()，源码里就这一行 - 就算你绕过编译去反射调用，底层
AbstractQueuedSynchronizer的ConditionObject也不支持共享节点加入等待队列
想让读线程等某个条件，有哪些可行替代方案
不能用 Condition，不等于不能等。关键是把「等待条件」和「持有读锁」解耦。
- 先释放读锁，用
Object.wait()或LockSupport.park()等待，条件满足后再重抢读锁（注意检查条件是否仍成立） - 用
StampedLock的乐观读 + 验证机制：tryOptimisticRead()获取戳，validate()检查是否失效，失效则退化为悲观读锁重试 - 把条件变量抽到锁外，比如用
AtomicBoolean+ 自旋 +Thread.onSpinWait()，适合等待时间极短的场景
示例：用 Object.wait() 替代读锁 Condition
立即学习“Java免费学习笔记（深入）”；
synchronized (conditionMonitor) {
while (!dataReady.get()) {
conditionMonitor.wait(); // 必须在 synchronized 块里
}
}
// 此时再获取 readLock() 安全读取
为什么写锁的 newCondition() 可以用，但实际也很少用
写锁是独占的，所以能合法构造 Condition，但它的使用场景非常受限。
- Condition 关联的是「当前持有写锁的线程」，一旦
signal()，被唤醒线程必须重新竞争写锁——可能立刻又被其他线程抢走，唤醒不等于能继续执行 - 如果唤醒后还要读数据，还得自己再手动降级为读锁，而
ReentrantReadWriteLock不支持锁降级以外的转换（写→读可以，读→写不行） - 绝大多数需要条件等待的业务，其实真正关心的是「数据状态变化」，而不是「写锁释放」，用
CountDownLatch或Phaser更直接
容易被忽略的关键点：锁语义和 Condition 语义根本不匹配
Condition 的本质是「某线程因某条件不满足而挂起，由另一线程显式唤醒」，这要求唤醒者能精准控制时机和目标。
但读锁的语义是「我只读，不改状态，也不负责通知别人」。让它承担条件等待职责，等于让一个只读用户去管理整个系统的事件分发——责任错位。
真正需要条件同步的地方，往往该用 java.util.concurrent 里更上层的工具：BlockingQueue、CompletableFuture、Phaser，而不是硬套 ReadWriteLock 的锁原语。
