继承Thread的子类在无其他线程调用await()时调用Condition.signal()会怎样？

问题1：继承自Thread的子类，在没有其他线程调用Condition.await()的情况下，能否调用Condition.signal()？ #

当然可以，而且绝对安全，不会抛出任何异常——前提是你调用signal()的时候，已经获取了这个Condition关联的Lock对象（毕竟Condition是和Lock绑定的，调用它的任何方法都必须先持有锁，不然会直接抛出IllegalMonitorStateException，这是硬性规则）。

如果满足持有锁的前提，哪怕没有任何线程在这个Condition上处于await()等待状态，调用signal()也只是个“无意义的空操作”而已。Condition的signal()本来就是用来唤醒等待队列里的线程，队列空的话，自然没东西可唤醒，不会对程序造成任何负面影响。和你的线程是不是继承自Thread子类完全没关系，只要是合法持有锁的线程，都能这么调用。

问题2：示例场景：Informer与Watcher两个线程共用同一个List，Informer负责向List中添加数据；当List为空或Informer正在访问List时，Watcher无法读取该集合。若Informer调用Condition.signal()，但Watcher未创建或未启动（即Watcher未调用Condition.await()），会产生什么结果？ #

简单说就是啥都不会发生，这个signal()调用完全无效，不会干扰程序的正常逻辑。

咱们拆解下这个场景：

• Watcher要么没被创建，要么没启动，那它根本没机会执行到获取锁、调用Condition.await()的步骤，自然不会进入这个Condition的等待队列。
• Informer调用signal()时，因为等待队列是空的，没有线程会被唤醒。从业务角度看，Watcher本来就没在等着读取List，所以不存在“应该被唤醒却没被唤醒”的问题，程序不会出现死锁、数据不一致这类问题，只是白做了一次无意义的调用而已。

还是要再强调一遍：Informer调用signal()时必须持有对应的Lock，这和Watcher是否存在无关——没锁就调用的话，不管有没有等待线程，都会直接抛出IllegalMonitorStateException。

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