Condition 不能直接 new 实例化，必须通过 ReentrantLock 的 newCondition() 方法获取，因其是接口且唯一实现类 ConditionObject 为 AQS 私有静态内部类，无公开构造器，且强依赖锁的同步状态和条件队列机制。
Condition 对象本身不能直接 new 实例化，它必须通过 ReentrantLock 的 newCondition() 方法获取。这是由 Java 并发设计决定的：Condition 与 Lock 强绑定，依赖锁的同步状态和等待队列机制，无法脱离具体锁实例独立存在。
Condition 是 Lock 的“配套等待工具”
ReentrantLock 内部维护一个 AQS（AbstractQueuedSynchronizer）同步队列，而每个 Condition 实例都关联一个独立的条件队列（Condition Queue），该队列由 AQS 的 ConditionNode 构成。调用 lock.newCondition() 时，实际创建的是 AbstractQueuedSynchronizer.ConditionObject 的实例——这是 AQS 提供的默认 Condition 实现，且被声明为 final，不可继承替换。
newCondition() 的底层行为
每次调用 ReentrantLock.newCondition()，都会新建一个 ConditionObject 实例，并将其加入当前锁的 condition 链表中。这个对象持有对所属 AQS 实例的引用，所有 await/signal 操作都通过该引用来修改同步状态、迁移线程节点、触发唤醒逻辑。
- 同一个
ReentrantLock可以创建多个 Condition 实例，各自拥有独立的等待队列 - 不同 Condition 的
await()调用会把当前线程加入对应条件队列，而非共享锁的同步队列 -
signal()只唤醒对应 Condition 队列队首的线程，不会影响其他 Condition 或同步队列中的线程
为什么不能 new Condition()？
Condition 是一个接口，没有公开构造方法；其唯一标准实现 ConditionObject 是 AQS 的私有静态内部类，不对外暴露构造器。JVM 不允许直接实例化接口，而反射绕过访问限制不仅破坏封装，还会因缺失 AQS 关联导致 await() 抛出 IllegalMonitorStateException 或死锁。
立即学习“Java免费学习笔记（深入）”；
例如以下写法是非法的：
❌ Condition cond = new ConditionObject(); // 编译失败，构造器不可见典型使用模式
正确用法始终遵循 “Lock → newCondition() → await/signal” 链路：
- 必须先获取锁（
lock.lock()），才能调用condition.await() -
await()会自动释放锁，并将线程挂起在该 Condition 队列上 -
signal()必须在持锁状态下调用，它将线程从 Condition 队列移至 AQS 同步队列，等待重新竞争锁
