如果一个人在谷歌上搜索“notify()和notifyAll()之间的区别”,那么会跳出很多解释(撇开javadoc段落)。这都归结于被唤醒的等待线程的数量:notify()中有一个,notifyAll()中有所有线程。
然而(如果我确实理解了这些方法之间的区别),只有一个线程总是被选择用于进一步的监视采集;第一种情况是VM选择的线程,第二种情况是系统线程调度程序选择的线程。程序员不知道它们的确切选择过程(在一般情况下)。
那么notify()和notifyAll()之间有什么有用的区别呢?我遗漏了什么吗?
我很惊讶居然没有人提到臭名昭著的“失醒”问题(谷歌it)。
基本上:
如果有多个线程在等待同一个条件,
可以让你从状态A转换到状态B的多个线程,
可以让你从状态B转换到状态A的多个线程(通常是与状态1相同的线程),
从状态A转换到状态B应该通知1中的线程。
然后,您应该使用notifyAll,除非您有可证明的保证,丢失的唤醒是不可能的。
一个常见的例子是并发FIFO队列,其中:
多个排队者(1。和3。)可以将队列从空转换为非空
多个退出队列器(2。上面)可以等待条件“队列不是空的”
Empty ->非空应该通知脱队列者
您可以很容易地编写一个交叉操作,其中从一个空队列开始,2个入队者和2个出队者交互,1个入队者保持休眠状态。
这是一个可以与死锁问题相比较的问题。
这里有一个例子。运行它。然后将notifyAll()中的一个更改为notify(),看看会发生什么。
ProducerConsumerExample类
public class ProducerConsumerExample {
private static boolean Even = true;
private static boolean Odd = false;
public static void main(String[] args) {
Dropbox dropbox = new Dropbox();
(new Thread(new Consumer(Even, dropbox))).start();
(new Thread(new Consumer(Odd, dropbox))).start();
(new Thread(new Producer(dropbox))).start();
}
}
Dropbox类
public class Dropbox {
private int number;
private boolean empty = true;
private boolean evenNumber = false;
public synchronized int take(final boolean even) {
while (empty || evenNumber != even) {
try {
System.out.format("%s is waiting ... %n", even ? "Even" : "Odd");
wait();
} catch (InterruptedException e) { }
}
System.out.format("%s took %d.%n", even ? "Even" : "Odd", number);
empty = true;
notifyAll();
return number;
}
public synchronized void put(int number) {
while (!empty) {
try {
System.out.println("Producer is waiting ...");
wait();
} catch (InterruptedException e) { }
}
this.number = number;
evenNumber = number % 2 == 0;
System.out.format("Producer put %d.%n", number);
empty = false;
notifyAll();
}
}
消费阶层
import java.util.Random;
public class Consumer implements Runnable {
private final Dropbox dropbox;
private final boolean even;
public Consumer(boolean even, Dropbox dropbox) {
this.even = even;
this.dropbox = dropbox;
}
public void run() {
Random random = new Random();
while (true) {
dropbox.take(even);
try {
Thread.sleep(random.nextInt(100));
} catch (InterruptedException e) { }
}
}
}
生产类
import java.util.Random;
public class Producer implements Runnable {
private Dropbox dropbox;
public Producer(Dropbox dropbox) {
this.dropbox = dropbox;
}
public void run() {
Random random = new Random();
while (true) {
int number = random.nextInt(10);
try {
Thread.sleep(random.nextInt(100));
dropbox.put(number);
} catch (InterruptedException e) { }
}
}
}
我想提一下《Java并发实践》中解释的内容:
第一点,是Notify还是NotifyAll?
It will be NotifyAll, and reason is that it will save from signall hijacking.
If two threads A and B are waiting on different condition predicates
of same condition queue and notify is called, then it is upto JVM to
which thread JVM will notify.
Now if notify was meant for thread A and JVM notified thread B, then
thread B will wake up and see that this notification is not useful so
it will wait again. And Thread A will never come to know about this
missed signal and someone hijacked it's notification.
So, calling notifyAll will resolve this issue, but again it will have
performance impact as it will notify all threads and all threads will
compete for same lock and it will involve context switch and hence
load on CPU. But we should care about performance only if it is
behaving correctly, if it's behavior itself is not correct then
performance is of no use.
这个问题可以通过使用jdk 5中提供的显式锁定Lock的Condition对象来解决,因为它为每个条件谓词提供了不同的等待。在这里,它将表现正确,不会有性能问题,因为它将调用信号,并确保只有一个线程正在等待该条件