能否不通过Lock获取而直接使用ConditionObject实现线程同步？

问题解答 #

1、能否直接使用ConditionObject配合synchronized方法实现wait/notify/notifyAll相关的线程调度功能？ #

不能，原因有两点：

• ConditionObject是AbstractQueuedSynchronizer（AQS）的protected修饰的内部类，正常场景下无法直接实例化，只能通过Lock实现类的newCondition()方法获取，它的所有实现逻辑强依赖绑定的AQS同步状态（也就是对应Lock的锁状态），和synchronized使用的JVM内置监视器锁完全是两套独立的同步机制。
• 就算你通过反射强行构造ConditionObject实例，调用它的await()/signal()方法时会校验当前线程是否持有绑定的Lock锁，你持有synchronized的监视器锁的情况下调用会直接抛出IllegalMonitorStateException，根本无法正常运行。

2、是否更推荐坚持使用Condition与Lock搭配的方案？ #

没有绝对的推荐，按需选择即可：

• 如果你的线程调度需求非常简单，synchronized + wait()/notify()完全可以覆盖，没必要额外引入Lock+Condition的复杂度。
• 如果你需要以下特性，Lock+Condition的方案会是更优选择：
  • 多条件等待队列：比如生产者消费者模型可以分别维护生产者、消费者两个独立的等待队列，signal()时只会唤醒对应队列的线程，避免notifyAll()带来的无效线程竞争
  • 可中断等待、超时等待、公平锁调度等synchronized不支持的能力
  • 更精细的线程调度控制

3、await()和传统的wait()/notify()之间是否存在性能差异？ #

核心逻辑的性能差异极小，大多数场景下你完全感知不到：

• 两者底层都需要做线程挂起、进入等待队列、被唤醒后竞争锁的操作，这部分开销是主要性能消耗，二者差别可以忽略。你看到的await()代码更多，是因为它额外实现了可中断、超时等待等多种特性的分支逻辑，这些判断的开销和线程上下文切换的开销比起来完全可以忽略。
• 高竞争多条件场景下，Condition的实际表现会优于原生的wait()/notify()：因为signal()只会唤醒对应条件队列的线程，不会像notifyAll()一样把所有等待在当前锁上的线程全部唤醒，大幅减少了无效的锁竞争开销，整体吞吐量会更高。

内容的提问来源于stack exchange，提问作者Nur1