jvm Object.wait/notify源码
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?
synchronized代码块通过javap生成的字节码中包含 monitorenter 和 ** monitorexit**指令。
执行monitorenter指令可以获取对象的monitor，而lock.wait()方法通过调用native方法wait(0)实现，其中接口注释中有这么一句
The current thread must own this object's monitor.
表示线程执行lock.wait()方法时，必须持有该lock对象的monitor，如果wait方法在synchronized代码中执行，该线程很显然已经持有了monitor。
代码分析
- 在多核环境下，线程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已经释放了锁？
- 线程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只能继续等待；
想要解答这些疑问， 需要分析jvm的相关实现，本文以HotSpot虚拟机1.7版本为例
什么是monitor？
在HotSpot虚拟机中，monitor采用ObjectMonitor实现。
image.png
每个线程都有两个ObjectMonitor对象列表，分别为free和used列表，如果当前free列表为空，线程将向全局global list请求分配ObjectMonitor。
ObjectMonitor对象中有两个队列：_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表；_owner指向获得ObjectMonitor对象的线程。
image.png
_WaitSet ：处于wait状态的线程，会被加入到wait set；
_EntryList：处于等待锁block状态的线程，会被加入到entry set；
ObjectWaiter
image.png
ObjectWaiter对象是双向链表结构，保存了_thread（当前线程）以及当前的状态TState等数据， 每个等待锁的线程都会被封装成ObjectWaiter对象。
wait方法实现
lock.wait()方法最终通过ObjectMonitor的void wait(jlong millis, bool interruptable, TRAPS);
1、将当前线程封装成ObjectWaiter对象node；
image.png
2、通过ObjectMonitor::AddWaiter方法将node添加到_WaitSet列表中；
image.png
3、通过ObjectMonitor::exit方法释放当前的ObjectMonitor对象，这样其它竞争线程就可以获取该ObjectMonitor对象。
image.png
4、最终底层的park方法会挂起线程；
notify方法实现
lock.notify()方法最终通过ObjectMonitor的void notify(TRAPS)实现：
1、如果当前_WaitSet为空，即没有正在等待的线程，则直接返回；
2、通过ObjectMonitor::DequeueWaiter方法，获取_WaitSet列表中的第一个ObjectWaiter节点，实现也很简单。
这里需要注意的是，在jdk的notify方法注释是随机唤醒一个线程，其实是第一个ObjectWaiter节点
image.png
3、根据不同的策略，将取出来的ObjectWaiter节点，加入到_EntryList或则通过Atomic::cmpxchg_ptr指令进行自旋操作cxq
notifyAll方法实现
lock.notifyAll()方法最终通过ObjectMonitor的void notifyAll(TRAPS)实现：
通过for循环取出_WaitSet的ObjectWaiter节点，并根据不同策略，加入到_EntryList或则进行自旋操作。
从JVM的方法实现中，可以发现：notify和notifyAll并不会释放所占有的ObjectMonitor对象，其实真正释放ObjectMonitor对象的时间点是在执行monitorexit指令，一旦释放ObjectMonitor对象了，entry set中ObjectWaiter节点所保存的线程就可以开始竞争ObjectMonitor对象进行加锁操作了。
注意默认策略下（Policy=2），当notify执行时，如果_EntryList为空则把wait线程放入到_EntryList，否则放入到_cxq的队首，当notify线程退出synchronzied时，唤醒_EntryList的第一个线程（如果_EntryList为空，则先将_cxq队列的元素移动到_EntryList）。 另外如果Policy的值not in {0,1,2,3}的时候，notify的时候将会直接唤醒线程。
1、在多核环境下，线程A和B有可能同时执行monitorenter指令，并获取lock对象关联的monitor，只有一个线程可以和monitor建立关联，假设线程A执行加锁成功；
2、线程B竞争加锁失败，进入entryset进行等待；
假如现在有线程A、线程B、线程C同时在争夺lock1。1.此时线程B比较幸运首先获取了lock1,此时线程A和线程C未获取到锁，此时状态为blocked,放在entryllist里。2.然后线程B发现有在等待加一个不可预期的资源，避免忙等，所以调用了lock1.wait(),此时线程B的状态变为waiting,底层会把线程B放到wait set里，此时线程C又获得了lock1,此时三个线程的状态是线程A blocked（entrylist里）,线程B waiting（wait set里）,线程C runnable.3.线程C 在线程里调用lock1.nofityall, 我这里有疑问是：当线程C调用nofityall后，是先把线程B从wait set里移出后加到entrylist里，此时entrylist里有线程A和线程B,然后一起竞争锁吗？
只要入了队列，再出队都是有先后顺序，因为它们本身入队出队就是按照链表的结构来的，AQS实现公平锁非公平锁一旦入队挂起，再出队也是按照顺序，公平与否是针对入队前而言的。
今天特意测试了一下，最终获取锁的前后顺序一定是：B在前，A在后。它们不会一起竞争锁，因为它们在同步队列中，虽然都处于BLOCKED状态，一定是一个接着一个获取锁（一个接着一个出队列）。结论就是它们一定是有顺序的.
