简单翻译一下: 当线程在某个条件变量下等待时,即使其他线程没有broadcast or signaled 这个条件变量,该线程仍然可能被唤醒,在多核处理器系统下,使条件变量完全可以预测会降低系统的性能,而导致虚假唤醒的几率又很小
综合我所了解到相关知识. 在操作系统底层"唤醒"的实现机制就注定虚假唤醒的存在,设计者们不解决这个问题的原因是
修复这个问题会导致系统性能下降,性价比太低
即使修复了这个问题,由于同步问题的存在,仍然要将wait()放进循环里.
原理解释
设两个consumer为C1,C2,producer为P.上面出现异常的时序如下:
要理解问题所在,需要了解以下知识
1.线程获取不到锁被阻塞,会在Contention List上等待
2.获取到锁的线程调用wait后,会主动放弃锁,并在Wait Set中等待唤醒
3.线程调用notify后,在退出Synchronized块释放锁后才会执行唤醒操作
上面问题的核心是: C1被唤醒后,仍然需要先获取锁再继续执行逻辑,而唤醒-获取锁并不是原子性的,唤醒之后锁可能被其他线程获取,这时C1再次获取到锁时,产品已经没了,由于是继续执行,就没有再检查产品数量,导致异常情况的出现
解决办法—将if替换为while
替换为while后,即使被唤醒,仍然会再检查一遍限制条件,保证逻辑的正确性.