synchronized(obj) 中的waitSet称为“等待队列”,那么这个队列是FIFO机制吗?或者是当调用obj.notify()方法后,是最先进入waitSet中的一个线程被唤醒吗?

这个问题,在网络各大论坛上面,很多人做出了自己的解答,给出的答案大多是否定的。

first example:

 the second:

 the third(被我看到逻辑不太对,所以拿来自己测试):

先说一下,为什么它逻辑不对,因为他每次唤醒一次,主线程就要争用锁一次。那么主线程和被唤醒的线程在争用锁呢,怎么可能得出不受干扰的结果呢?

 the last(黑马程序员):

 我想应该是他们没有理解从waitSet里面取出线程唤醒和唤醒后争用到锁是两回事。而他们只看锁争用的结果表象的话,就误认为,线程唤醒是随机的。

下面是我的测试代码:

public void test() throws InterruptedException {
        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();
                }
           
            
        }

执行了很多次,得到的结果,我贴到下面:

1 will come to wait set.
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("唤醒了第一个");
        }

运行得到的结果:

1 will come to wait set.
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)默认是0

Qmode=0的判断逻辑就是先判断entrylist是否为空,如果不为空,则取出第一个唤醒,如

果为空,将cxq里面线程按照头尾顺序,全量放入EntryList,再从EntryList中获取第一个唤醒。

        在默认策略policy == 2的情况下,waitSet取出的线程放到entryList(待入队列)之后,entryList不为空,那么剩下的线程都会进入到cxq(contention List争用队列),在默认策略下,cxq变成了FILO的,也就是说它此时的逻辑是个栈(从排头入,从排头取),先入后出,所以后面的线程拿到锁的顺序是倒序的。

当我将notify()改成notifyAll()之后:

synchronized (ref) {
            for (int i = 0; i < 1; i++) {
                ref.notifyAll();
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }

运行的结果:

1 will come to wait set.
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中获取第一个唤醒。产生了如上结果。

如果你觉得我的博客内容对你有帮助,请关注我的公众号,更多的学习资料,源码解析,设计思想,方案推陈,都可以与你分享,共同进步。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值