java monitor

【个人笔记搬运到博客系列】

一、monitor概念

在操作系统中，存在着semaphore和mutex，为了更好的编写并发程序，在mutex和semaphore基础上，提出了更高层次的同步原语，实际上，monitor属于编程语言的范畴，具体的实现模式，不同的编程语言都有可能不一样，C语言不支持monitor，而java支持monitor机制。

一个重要特点是，在同一时间，只有一个线程/进程能进入monitor所定义的临界区，这使得monitor能够实现互斥的效果。无法进入monitor的临界区的进程/线程，应该被阻塞，并且在适当的时候被唤醒。显然，monitor作为一个同步工具，也应该提供这样管理线程/进程的机制。

monitor这个机制之所以被称为：更高级的原语，它不可避免的需要对外屏蔽这些机制，并且在内部实现这些机制；

二、monitor基本元素

• 临界区
• monitor对象和锁
• 条件变量，以及定义在monitor对象上的wait，notify操作

使用monitor主要是为了互斥进入临界区，为了能够阻塞无法进入临界区的进程，线程，需要一个monitor object来协助，这个object内部会有相应的数据结构，例如列表，用来保存被阻塞的线程；同时由于monitor机制本质是基于mutex原语的，所以object必须维护一个基于mutex的锁。

此外，为了在适当的时候能够阻塞和唤醒 进程/线程，还需要引入一个条件变量，这个条件变量用来决定什么时候是“适当的时候”，这个条件可以来自程序代码的逻辑，也可以是在 monitor object 的内部，总而言之，程序员对条件变量的定义有很大的自主性。不过，由于 monitor object 内部采用了数据结构来保存被阻塞的队列，因此它也必须对外提供两个 API 来让线程进入阻塞状态以及之后被唤醒，分别是 wait 和 notify。

三、monitor在java中的实现

临界区：被synchronized关键字修饰的方法，代码块，就是monitor机制的临界区；

monitor object：在上述synchronized关键字被使用时，往往需要指定一个对象与之关联，例如synchronized（this）,总之，synchronized需要管理一个对象，这个对象就是monitor object。

Java 对象存储在内存中，分别分为三个部分，即对象头、实例数据（对象体）和对齐填充，而在其对象头中，保存了锁标识；同时，java.lang.Object 类定义了 wait()，notify()，notifyAll() 方法，这些方法的具体实现，依赖于一个叫 ObjectMonitor 模式的实现，这是 JVM 内部基于 C++ 实现的一套机制，基本原理如下所示：

以下以 Java 的 monitor 为例子，来讲解 monitor 在 Java 中的实现方式：

在Java中，一个对象对应了一个momitor对象，而synchronized关键字也需要关联一个对象，这个对象需要天生就支持monitor，所以在Java中，可以就是Java 中的 java.lang.Object 类，便是满足这个要求的对象，任何一个 Java 对象都可以作为 monitor 机制的 monitor object。这也就是wait(),notify(),notifyAll(),是在Object类中的原因。

四、monitor详解

4.1、线程状态

　Java中线程中状态可分为五种：New（新建状态），Runnable（就绪状态），Running（运行状态），Blocked（阻塞状态），Dead（死亡状态）。

New：新建状态，当线程创建完成时为新建状态，即new Thread(...)，还没有调用start方法时，线程处于新建状态。

Runnable：就绪状态，当调用线程的的start()方法后，线程进入就绪状态，等待CPU资源。处于就绪状态的线程由Java运行时系统的线程调度程序(thread scheduler)来调度。

Running：运行状态，就绪状态的线程获取到CPU执行权以后进入运行状态，开始执行run()方法。

Blocked：阻塞状态，线程没有执行完，由于某种原因（如，I/O操作等）让出CPU执行权，自身进入阻塞状态。

Dead：死亡状态，线程执行完成或者执行过程中出现异常，线程就会进入死亡状态。

这五种状态之间的转换关系如下图所示：

4.2、wait/notify/notifyAll方法的使用

【1】wait方法

有三种版本：

（1）wait()，作用是将当前运行的线程挂起（即让其进入阻塞状态），直到notify或notifyAll方法来唤醒线程；

（2）wait(long timeout)，该方法与wait()方法类似，唯一的区别就是在指定时间内，如果没有notify或notifAll方法的唤醒，也会自动唤醒；

（3）wait(long timeout,long nanos)，在于更精确的控制调度时间；

核心：wait方法的使用必须在同步的范围内，否则就会抛出IllegalMonitorStateException异常，wait方法的作用就是阻塞当前线程等待notify/notifyAll方法的唤醒，或等待超时后自动唤醒。

public class WaitTest {

    public void testWait(){
        System.out.println("Start-----");
        try {
            wait(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("End-------");
    }

    public static void main(String[] args) {
        final WaitTest test = new WaitTest();
        new Thread(new Runnable() {
            @Override
            public void run() {
                test.testWait();
            }
        }).start();
    }
}

如果按照以上代码这么写，会抛出IllegalMonitorStateException异常，意思是：线程试图等待对象的监视器或者试图通知其他正在等待对象监视器的线程，但本身没有对应的监视器的所有权。

由于wait方法是一个本地方法，其底层是通过一个叫做监视器锁的对象monitor来完成的。所以上面之所以会抛出异常，是因为在调用wait方式时没有获取到monitor对象的所有权，那如何获取monitor对象所有权？Java中只能通过Synchronized关键字来完成，修改上述代码，增加Synchronized关键字，即可运行：

public class WaitTest {

    public synchronized void testWait(){//增加Synchronized关键字
        System.out.println("Start-----");
        try {
            wait(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("End-------");
    }

    public static void main(String[] args) {
        final WaitTest test = new WaitTest();
        new Thread(new Runnable() {
            @Override
            public void run() {
                test.testWait();
            }
        }).start();
    }
}

通过上述代码示例，可以看出，wait方法的使用必须在同步的范围内，否则就会抛出IllegalMonitorStateException异常，wait方法的作用就是阻塞当前线程等待notify/notifyAll方法的唤醒，或等待超时后自动唤醒。

【2】notify/notifyall

有了对wait方法原理的理解，notify方法和notifyAll方法就很容易理解了。既然wait方式是通过对象的monitor对象来实现的，所以只要在同一对象上去调用notify/notifyAll方法，就可以唤醒对应对象monitor上等待的线程了。notify和notifyAll的区别在于前者只能唤醒monitor上的一个线程，对其他线程没有影响，而notifyAll则唤醒所有的线程。

有两点点需要注意：

（1）调用wait方法后，线程是会释放对monitor对象的所有权的。

（2）一个通过wait方法阻塞的线程，必须同时满足以下两个条件才能被真正执行：

　　　　线程需要被唤醒（超时唤醒或调用notify/notifyll）。
　　　　线程唤醒后需要竞争到锁（monitor）。

4.3、sleep/yield/join方法使用：

再来看另外一组线程间协作的方法。这组方法跟上面方法的最明显区别是：这几个方法都位于Thread类中，而上面三个方法都位于Object类中。

【1】sleep方法

sleep方法的作用是让当前线程暂停指定的时间（毫秒），sleep方法是最简单的方法，比较容易理解。

唯一需要注意的是其与wait方法的区别。最简单的区别是，wait方法依赖于同步，而sleep方法可以直接调用。而更深层次的区别在于sleep方法只是暂时让出CPU的执行权，并不释放锁。而wait方法则需要释放锁。

通过sleep方法实现的暂停，程序是顺序进入同步块的，只有当上一个线程执行完成的时候，下一个线程才能进入同步方法，sleep暂停期间一直持有monitor对象锁，其他线程是不能进入的。而wait方法则不同，当调用wait方法后，当前线程会释放持有的monitor对象锁，因此，其他线程还可以进入到同步方法，线程被唤醒后，需要竞争锁，获取到锁之后再继续执行。

【2】yield方法
yield方法的作用是暂停当前线程，以便其他线程有机会执行，不过不能指定暂停的时间，并且也不能保证当前线程马上停止。yield方法只是将Running状态转变为Runnable状态。

不过请注意：这种交替并不一定能得到保证，而且源码中也对这个问题进行了说明，意思总结是：调度器可能会忽略该方法；使用的时候要仔细分析和测试，确保能达到预期的效果；很少有场景要用到该方法，主要使用的地方是调试和测试。

【3】join方法

有三个版本：

void join()    
void join(long millis)
void join(long millis, int nanos)

join方法的作用是：父线程等待子线程执行完成后再执行，换句话说就是将异步执行的线程合并为同步的线程。JDK中提供三个版本的join方法，其实现与wait方法类似，join()方法实际上执行的join(0)，而join(long millis, int nanos)也与wait(long millis, int nanos)的实现方式一致，暂时对纳秒的支持也是不完整的。

重点关注一下join(long millis)方法的实现，可以看出join方法就是通过wait方法来将线程的阻塞，如果join的线程还在执行，则将当前线程阻塞起来，直到join的线程执行完成，当前线程才能执行。不过有一点需要注意，这里的join只调用了wait方法，却没有对应的notify方法，原因是Thread的start方法中做了相应的处理，所以当join的线程执行完成以后，会自动唤醒主线程继续往下执行。

在没有使用join方法之间，线程是并发执行的，而使用join方法后，所有线程是顺序执行的。

总结：

以上这部分详细讲解了wait/notify/notifyAll和sleep/yield/join方法。

最后回答一个问题：wait/notify/notifyAll方法的作用是实现线程间的协作，那为什么这三个方法不是位于Thread类中，而是位于Object类中？

位于Object中，也就相当于所有类都包含这三个方法（因为Java中所有的类都继承自Object类）。要回答这个问题，还是得回过来看wait方法的实现原理，大家需要明白的是，wait等待的到底是什么东西？如果对上面内容理解的比较好的话，我相信大家应该很容易知道wait等待其实是对象monitor，由于Java中的每一个对象都有一个内置的monitor对象，自然所有的类都理应有wait/notify方法。

4.4、monitor详解：

Java平台中，每个对象都有一个唯一与之对应的内部锁（Monitor）。Java虚拟机会为每个对象维护两个“队列”（姑且称之为“队列”，尽管它不一定符合数据结构上队列的“先进先出”原则）：一个叫Entry Set（入口集），另外一个叫Wait Set（等待集）。对于任意的对象objectX，objectX的Entry Set用于存储等待获取objectX对应的内部锁的所有线程。objectX的Wait Set用于存储执行了objectX.wait()/wait(long)的线程。

 

设objectX是任意一个对象，monitorX是这个对象对应的内部锁，假设有线程A、B、C同时申请monitorX，那么由于任意一个时刻只有一个线程能够获得（占用/持有）这个锁，因此除了胜出（即获得了锁）的线程（这里假设是B）外，其他线程（这里就是A和C）都会被暂停（线程的生命周期状态会被调整为BLOCKED）。这些因申请锁而落选的线程就会被存入objectX对应的Entry Set（以下记为entrySetX）之中。当monitorX被其持有线程（这里就是B）释放时，entrySetX中的一个任意（注意是“任意”，而不一定是Entry Set中等待时间最长或者最短的）线程会被唤醒（即线程的生命周期状态变更为RUNNABLE）。这个被唤醒的线程会与其他活跃线程（即不处于Entry Set之中，且线程的生命周期状态为RUNNABLE的线程）再次抢占monitorX。这时，被唤醒的线程如果成功申请到monitorX，那么该线程就从entrySetX中移除。否则，被唤醒的线程仍然会停留在entrySetX，并再次被暂停，以等待下次申请锁的机会。

 

如果有个线程执行了objectX.wait()，那么该线程就会被暂停（线程的生命周期状态会被调整为WAITTING）并被存入objectX的Wait Set（以下记为waitSetX）之中。此时，该线程就被称为objectX的等待线程。当其他线程执行了objectX.notify()/notifyAll()时，waitSetX中的一个（或者多个，取决于被调用的是notify还是notifyAll方法）任意（注意是“任意”，而不一定是Entry Set中等待时间最长或者最短的）等待线程会被唤醒（线程的生命周期状态变更为RUNNABLE）。这些被唤醒的线程会与entrySetX中被唤醒的线程以及其他（可能的）活跃线程共同参与抢夺monitorX。如果其中一个被唤醒的等待线程成功申请到锁，那么该线程就会从waitSetX中移除。否则，这些被唤醒的线程仍然停留在waitSetX中，并再次被暂停，以等待下次申请锁的机会。

问题：我理解调用对象的 notifyAll方法后，waitSet 上的线程都会加入到 entrySet 中的吧？在一个持有锁的线程释放锁后，应该只有 entrySet 队列的线程可能获取锁，那这个通知是 park 来实现的吗？是否有保证获取锁公平性的相关设置?

【1】从Java虚拟机性能的角度来说，Java虚拟机没有必要在notifyAll调用之后“将Wait Set中的线程移入Entry Set”。首先，从一个“队列”移动到另外一个“队列”是有开销的，其次，虽然notifyAll调用后Wait Set中的多个线程会被唤醒，但是这些被唤醒的线程极端情况下可能没有任何一个能够获得锁（比如被其他活跃线程抢先下手了）或者即便可以获得锁也可能不能继续运行（比如这些等待线程所需的等待条件又再次不成立）。那么这个时候，这些等待线程仍然需要老老实实在wait set中待着。因此，如果notifyAll调用之后就将等待线程移出wait set会导致浪费（白白地进出“队列”）。这点可以参考显式锁的实现：

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Node, int)

 /**
 * Acquires in exclusive uninterruptible mode for thread already in
 * queue. Used by condition wait methods as well as acquire.
 *
 * @param node the node
 * @param arg the acquire argument
 * @return {@code true} if interrupted while waiting
 */
final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

从上面的代码可以看出，（使用显式锁时）被唤醒的线程获得锁（tryAcquire调用返回true）之后才被从wait set中移出（setHead调用）。

【2】内部锁仅仅支持非公平锁调度。显式锁既支持公平锁又支持非公平锁。

LockSupport.park/upark是在jdk1.5开始引入的，显式锁的在实现线程的暂停和唤醒的时候会用到这个两个方法。而内部锁是在jdk1.5之前就已经存在的。

 

 

参考：

Java 并发编程：线程间的协作(wait/notify/sleep/yield/join)：https://www.cnblogs.com/paddix/p/5381958.html
java的锁池和等待池：https://www.cnblogs.com/tiancai/p/9371655.html