synchronized块与显式Lock锁机制对比及异常原因解析

核心原因 #

Condition的await()/signal()/signalAll()方法有严格的前置要求：当前线程必须持有创建该Condition的显式Lock实例。你的错误在于混淆了Java的两种完全独立的锁机制——内置锁（synchronized）和显式Lock（ReentrantLock）。

显式Lock与Condition的绑定规则 #

你代码里的incrementCondition和releaseCondition是通过lock.newCondition()创建的，它们本质上和这个ReentrantLock实例绑定。只有当线程通过lock.lock()获取到这个显式锁后，才能合法调用这两个Condition的等待/通知方法，否则就会抛出IllegalMonitorStateException。

当你用lock.lock()和lock.unlock()包裹代码时，线程正确持有了Condition对应的显式锁，所有操作都符合规则，代码自然正常运行。

synchronized块的问题所在 #

synchronized(lock)获取的是lock对象的内置监视器锁（每个Java对象自带的锁），这个锁和ReentrantLock的显式锁没有任何关联。此时线程虽然持有了对象的内置锁，但并没有持有Condition绑定的显式Lock，调用Condition的方法必然违反其前置条件，触发异常。

简单总结两套锁体系的使用规则：

• 用synchronized时，必须配套使用Object.wait()/Object.notify()/Object.notifyAll()；
• 用显式Lock时，必须配套使用Condition.await()/Condition.signal()/Condition.signalAll()；
• 跨体系混用一定会触发锁状态不匹配的异常。

额外提醒 #

显式Lock的优势在于支持多Condition、可中断锁、公平锁等特性，这是内置锁做不到的。但使用时必须严格遵守规则：调用Condition方法前必须持有对应的Lock，且锁的获取和释放要配对（建议用try-finally包裹，避免异常导致锁未释放）。

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