这个问题，在网络各大论坛上面，很多人做出了自己的解答，给出的答案大多是否定的。
first example：
The Second:
the third(被我看到逻辑不太对，所以拿来自己测试):
先说一下，为什么它逻辑不对，因为他每次唤醒一次，主线程就要争用锁一次。那么主线程和被唤醒的线程在争用锁呢，怎么可能得出不受干扰的结果呢？
the last(黑马程序员)：
我想应该是他们没有理解从waitSet里面取出线程唤醒和唤醒后争用到锁是两回事。而他们只看锁争用的结果表象的话，就误认为，线程唤醒是随机的。
下面是我的测试代码：
Object ref = new Object();
IntStream.rangeClosed(1, 10).forEach(i ->
{
new Thread(String.valueOf(i)) {
@Override
public void run() {
synchronized (ref) {
try {
System.out.println(Thread.currentThread().getName() + " will come to wait set.");
ref.wait();
System.err.println(Thread.currentThread().getName() + " will leave to wait set.");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}.start();
try {
Thread.sleep(1000);
}catch (Exception e){
e.printStackTrace();
}
});
Thread.sleep(3000);
synchronized (ref) {
ref.notify();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
执行了很多次，得到的结果，我贴到下面：
2 will come to wait set.
3 will come to wait set.
4 will come to wait set.
5 will come to wait set.
6 will come to wait set.
7 will come to wait set.
8 will come to wait set.
9 will come to wait set.
10 will come to wait set.
唤醒了第一个
1 will leave to wait set.
从结果来看，调用obj.notify()唤醒的就是第一个进入entrySet的线程。
下面我将唤醒逻辑改成将所有的waiting线程都唤醒是什么状况：
synchronized (ref) {
for (int i = 0; i < 10; i++) {
ref.notify();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println("唤醒了第一个");
}
运行得到的结果：
2 will come to wait set.
3 will come to wait set.
4 will come to wait set.
5 will come to wait set.
6 will come to wait set.
7 will come to wait set.
8 will come to wait set.
9 will come to wait set.
10 will come to wait set.
1 will leave to wait set.
10 will leave to wait set.
9 will leave to wait set.
8 will leave to wait set.
7 will leave to wait set.
6 will leave to wait set.
5 will leave to wait set.
4 will leave to wait set.
3 will leave to wait set.
2 will leave to wait set.
不管执行多少次，运行得到的结果总是同一个。说明就算全部唤醒，最先被唤醒是永远是第一个进入waitSet的线程。但是后面的线程的为什么开始倒数了呢？我们来看下notify()的策略，和锁释放后，线程争用锁的策略：
notify（） 根据Policy 做不同的操作
Policy==0 ：放入到entrylist队列的排头位置
Policy==1 ：放入到entrylist队列的末尾位置
Policy==2 ：判断entrylist是否为空，为空就放入entrylist中，否则放入cxq队列排头位置（默认
策略）
Policy==3 ：判断cxq是否为空，如果为空，直接放入头部，否则放入cxq队列末尾位置
当同步代码块执行完毕，唤醒是什么样子的呢？根据Qmode进行选择
根据QMode策略唤醒：
QMode=2，取cxq头部节点直接唤醒
QMode=3，如果cxq非空，把cxq队列放置到entrylist的尾部（顺序跟cxq一致）
QMode=4，如果cxq非空，把cxq队列放置到entrylist的头部（顺序跟cxq相反）
QMode=0，(QMode默认是0）Qmode=0的判断逻辑就是先判断entrylist是否为空，如果不为空，则取出第一个唤醒，如果为空,将cxq里面线程按照头尾顺序，全量放入EntryList,再从EntryList中获取第一个唤醒。
在默认策略policy == 2的情况下，waitSet取出的线程放到entryList（待入队列）之后，entryList不为空，那么剩下的线程都会进入到cxq（contention List争用队列）,在默认策略下，cxq变成了FILO的，也就是说它此时的逻辑是个栈（从排头入，从排头取），先入后出，所以后面的线程拿到锁的顺序是倒序的。
for (int i = 0; i < 1; i++) {
ref.notifyAll();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
运行的结果：
2 will come to wait set.
3 will come to wait set.
4 will come to wait set.
5 will come to wait set.
6 will come to wait set.
7 will come to wait set.
8 will come to wait set.
9 will come to wait set.
10 will come to wait set.
10 will leave to wait set.
9 will leave to wait set.
8 will leave to wait set.
7 will leave to wait set.
6 will leave to wait set.
5 will leave to wait set.
4 will leave to wait set.
3 will leave to wait set.
2 will leave to wait set.
1 will leave to wait set.
说明notifyAll()的策略跟notify的不一样，因为唤醒的线程比较多，不会给任何一个待唤醒的线程优先权而进入EntryList，所以它跟线程正常的争用锁机制一样，不会管entryList是否为空，直接一股脑全部从排头放入cxq了，然后这段代码释放锁之后，cxq里面线程按照头尾顺序，全量放入EntryList,再从EntryList中获取第一个唤醒。产生了如上结果。
如果你觉得我讲的不错，就请点个关注和赞再走吧。部分图片来自我的CSDN博客：t.csdnimg.cn/2guFE
更多内容，请关注我的公众号：砥砺code
