JVM源码分析之Object.wait/notify实现

川长思鸟来 2021-06-10 20:38 365阅读 0赞

最简单的东西，往往包含了最复杂的实现，因为需要为上层的存在提供一个稳定的基础，Object作为java中所有对象的基类，其存在的价值不言而喻，其中wait和notify方法的实现多线程协作提供了保证。

public class WaitNotifyCase {
        public static void main(String[] args) {
            final Object lock = new Object();
    
            new Thread(new Runnable() {
                @Override
                public void run() {
                    System.out.println("thread A is waiting to get lock");
                    synchronized (lock) {
                        try {
                            System.out.println("thread A get lock");
                            TimeUnit.SECONDS.sleep(1);
                            System.out.println("thread A do wait method");
                            lock.wait();
                            System.out.println("wait end");
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                    }
                }
            }).start();
    
            new Thread(new Runnable() {
                @Override
                public void run() {
                    System.out.println("thread B is waiting to get lock");
                    synchronized (lock) {
                        System.out.println("thread B get lock");
                        try {
                            TimeUnit.SECONDS.sleep(5);
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                        lock.notify();
                        System.out.println("thread B do notify method");
                    }
                }
            }).start();
        }
    }

执行结果：

> thread A is waiting to get lock  
> thread A get lock  
> thread B is waiting to get lock  
> thread A do wait method  
> thread B get lock  
> thread B do notify method  
> wait end

**前提**：由同一个lock对象调用wait、notify方法。  
1、当线程A执行wait方法时，该线程会被挂起；  
2、当线程B执行notify方法时，会唤醒一个被挂起的线程A；

lock对象、线程A和线程B三者是一种什么关系？根据上面的结论，可以想象一个场景：  
1、lock对象维护了一个等待队列list；  
2、线程A中执行lock的wait方法，把线程A保存到list中；  
3、线程B中执行lock的notify方法，从等待队列中取出线程A继续执行；  
当然了，Hotspot实现不可能这么简单。

上述代码中，存在多个疑问：

1、进入wait/notify方法之前，为什么要获取synchronized锁？  
2、线程A获取了synchronized锁，执行wait方法并挂起，线程B又如何再次获取锁？

为什么要使用synchronized?

static void Sort(int [] array) {
        // synchronize this operation so that some other thread can't
        // manipulate the array while we are sorting it. This assumes that other
        // threads also synchronize their accesses to the array.
        synchronized(array) {
            // now sort elements in array
        }
    }

synchronized代码块通过javap生成的字节码中包含 \*\* monitorenter \*\* 和 \*\* monitorexit \*\*指令。

![format_png][]

执行monitorenter指令可以获取对象的monitor，而lock.wait()方法通过调用native方法wait(0)实现，其中接口注释中有这么一句：

> The current thread must own this object's monitor.

表示线程执行lock.wait()方法时，必须持有该lock对象的monitor，如果wait方法在synchronized代码中执行，该线程很显然已经持有了monitor。

代码执行过程分析

1、在多核环境下，线程A和B有可能同时执行monitorenter指令，并获取lock对象关联的monitor，只有一个线程可以和monitor建立关联，假设线程A执行加锁成功；  
2、线程B竞争加锁失败，进入等待队列进行等待；  
3、线程A继续执行，当执行到wait方法时，会发生什么？wait接口注释：

> This method causes the current thread to place itself in the wait set for this object and then to relinquish any and all synchronization claims on this object.

wait方法会将当前线程放入wait set，等待被唤醒，并放弃lock对象上的所有同步声明，意味着线程A释放了锁，线程B可以重新执行加锁操作，不过又有一个疑问：在线程A的wait方法释放锁，到线程B获取锁，这期间发生了什么？线程B是如何知道线程A已经释放了锁？好迷茫....

4、线程B执行加锁操作成功，对于notify方法，JDK注释：notify方法会选择wait set中任意一个线程进行唤醒；

> Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation

notifyAll方法的注释：notifyAll方法会唤醒monitor的wait set中所有线程。

> Wakes up all threads that are waiting on this object's monitor.

5、执行完notify方法，并不会立马唤醒等待线程，在notify方法后面加一段sleep代码就可以看到效果，如果线程B执行完notify方法之后sleep 5s，在这段时间内，线程B依旧持有monitor，线程A只能继续等待；

**那么wait set的线程什么时候会被唤醒？**

> 想要解答这些疑问， 需要分析jvm的相关实现，本文以HotSpot虚拟机1.7版本为例

### 什么是monitor？ ###

在HotSpot虚拟机中，monitor采用ObjectMonitor实现。

![format_png 1][]

每个线程都有两个ObjectMonitor对象列表，分别为free和used列表，如果当前free列表为空，线程将向全局global list请求分配ObjectMonitor。

ObjectMonitor对象中有两个队列：\_WaitSet 和 \_EntryList，用来保存ObjectWaiter对象列表；\_owner指向获得ObjectMonitor对象的线程。

![format_png 2][]

\*\*\_WaitSet \*\* ：调用wait()后处于wait状态的线程，会被加入到wait set；进入WaitList中的线程在notify()/notifyAll()调用后会被加入到EntryList。  
**\_EntryList（锁候选者列表）**：处于等待锁block状态的线程，会被加入到entry set；

ObjectWaiter

![format_png 3][]

ObjectWaiter对象是双向链表结构，保存了\_thread（当前线程）以及当前的状态TState等数据， 每个等待锁的线程都会被封装成ObjectWaiter对象。

### wait方法实现 ###

`lock.wait()`方法最终通过ObjectMonitor的`void wait(jlong millis, bool interruptable, TRAPS);`实现：  
1、将当前线程封装成ObjectWaiter对象node；

![format_png 4][]

2、通过`ObjectMonitor::AddWaiter`方法将node添加到\_WaitSet列表中；

![format_png 5][]

3、通过`ObjectMonitor::exit`方法释放当前的ObjectMonitor对象，这样其它竞争线程就可以获取该ObjectMonitor对象。

![format_png 6][]

4、最终底层的park方法会挂起线程；

### notify方法实现 ###

`lock.notify()`方法最终通过ObjectMonitor的`void notify(TRAPS)`实现：  
1、如果当前\_WaitSet为空，即没有正在等待的线程，则直接返回；  
2、通过`ObjectMonitor::DequeueWaiter`方法，获取\_WaitSet列表中的第一个ObjectWaiter节点，实现也很简单。  
**这里需要注意的是，在jdk的notify方法注释是随机唤醒一个线程，其实是第一个ObjectWaiter节点**

![format_png 7][]

3、根据不同的策略，将取出来的ObjectWaiter节点，加入到\_EntryList或则通过`Atomic::cmpxchg_ptr`指令进行自旋操作cxq，具体代码实现有点长，这里就不贴了，有兴趣的同学可以看objectMonitor::notify方法；

### notifyAll方法实现 ###

`lock.notifyAll()`方法最终通过ObjectMonitor的`void notifyAll(TRAPS)`实现：  
通过for循环取出\_WaitSet的ObjectWaiter节点，并根据不同策略，加入到\_EntryList或则进行自旋操作。

从JVM的方法实现中，可以发现：notify和notifyAll并不会释放所占有的ObjectMonitor对象，其实真正释放ObjectMonitor对象的时间点是在执行monitorexit指令，一旦释放ObjectMonitor对象了，entry set中ObjectWaiter节点所保存的线程就可以开始竞争ObjectMonitor对象进行加锁操作了。

[format_png]: /images/20210527/d2fda82420db4c91b92998135ef8fc63.png
[format_png 1]: /images/20210527/0f786a87e94e44df9e73486a69268822.png
[format_png 2]: /images/20210527/0425b0a6a17744e79748efb51ebe5166.png
[format_png 3]: /images/20210527/78e444731b8346aa83a91e0d4f7b28a0.png
[format_png 4]: /images/20210527/332b4ef9d5394554b4e7aa9404d108d5.png
[format_png 5]: /images/20210527/3756a4fa7df34e6d87a92072f267599d.png
[format_png 6]: /images/20210527/3436e24a1185465ead2d47e45c6dc5f3.png
[format_png 7]: /images/20210527/2c7047c6e6284078b5c0fcf70af9978c.png