java线程协作---错失的信号（thinking in java 笔记）

本文探讨了Java中多线程协同工作的实现方式，并详细分析了使用wait()和notify()时可能出现的问题及解决方法，避免因线程切换导致的死锁。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

java中多线程协同工作是经常的事，众所周知这种协同大多是通过wait()和notify()或者notifyAll()来实现的，然而在这个实现中有一点还是值得注意的。请看下面的示例：

thread1:
synchronized(sharedMonitor)
{
      someCondition = false;
      sharedMonitor.notify();
}

thread2:
while(someCondition)
{
	//point 1
	synchronized(sharedMonitor)
	{
		sharedMonitor.wait();
	}
}

如果thread2先执行，执行到point 1的时候线程调度器将线程切换到thread1，thread1执行其设置并执行notify()，而此时线程切回thread2继续执行完，这个时候，thread2就会进入无限的忙等状态，因为在它执行wait()之前thread1已经执行完了notify()，因此thread2就错失这个信号，这样就会产生死锁。这个问题的解决方案是防止在在someCondition变量上产生竞争条件，如果将thread2修改为下面这样就可以达到这个目的了：

synchronized(sharedMonitor)
{
	while(someCondition)
	{
	    sharedMonitor.wait();
	}
}

这个时候如果thread1先执行，无论在何处线程发生切换，thread2都不可能执行，因为thread1没有释放sharedMonitor对象上的锁，thread2只能等待thread1执行完并释放锁之后才可以执行，而当thread1执行完后someCondition的值被修改这一事件就会被thread2所捕获，这样在someCondition=false的条件下thread2不会进入wait()状态，相反加入thread2先执行，同样不论线程切换在何处发生，thread1都必须等到thread2中的synchronized代码块全部执行完才可以执行，因为thread2已经获取了sharedMonitor对象的锁且必须等到wait()执行完毕之后才会释放锁，所以这个时候thread2就不会错失thread1的notify信号。