jvm源码解读--17 Java的wait()、notify()学习

write and debug by 张艳涛

wait()和notify()的通常用法

1. A线程取得锁，执行wait()，释放锁;
2. B线程取得锁，完成业务后执行notify()，再释放锁;
3. B线程释放锁之后，A线程取得锁，继续执行wait()之后的代码；

关于synchronize修饰的代码块
通常，对于synchronize(lock){…}这样的代码块，编译后会生成monitorenter和monitorexit指令，线程执行到monitorenter指令时会尝试取得lock对应的monitor的所有权（CAS设置对象头），取得后即获取到锁，执行monitorexit指令时会释放monitor的所有权即释放锁；

一个完整的demo
为了深入学习wait()和notify()，先用完整的demo程序来模拟场景吧，以下是源码：

package com.zyt.wait_notify;

public class NotifyDemo {

    private static void sleep(long sleepVal){
        try{
            Thread.sleep(sleepVal);
        }catch(Exception e){
            e.printStackTrace();
        }
    }

    private static void log(String desc){
        System.out.println(Thread.currentThread().getName() + " : " + desc);
    }

    Object lock = new Object();

    public void startThreadA(){
        new Thread(() -> {
            synchronized (lock){
                log("get lock");
                startThreadB();
                log("start wait");
                try {
                    
                }catch(InterruptedException e){
                    e.printStackTrace();
                }

                log("get lock after wait");
                log("release lock");
            }
        }, "thread-A").start();
    }

    public void startThreadB(){
        new Thread(()->{
            synchronized (lock){
                log("get lock");
                startThreadC();
                sleep(100);
                log("start notify");
                lock.notify();
                log("release lock");

            }
        },"thread-B").start();
    }

    public void startThreadC(){
        new Thread(() -> {
            synchronized (lock){
                log("get lock");
                log("release lock");
            }
        }, "thread-C").start();
    }

    public static void main(String[] args){
        new NotifyDemo().startThreadA();
    }
}

以上就是本次实战用到的demo，代码功能简述如下：

启动线程A，取得锁之后先启动线程B再执行wait()方法，释放锁并等待；
线程B启动之后会等待锁，A线程执行wait()之后，线程B取得锁，然后启动线程C，再执行notify唤醒线程A，最后退出synchronize代码块，释放锁;
线程C启动之后就一直在等待锁，这时候线程B还没有退出synchronize代码块，锁还在线程B手里；
线程A在线程B执行notify()之后就一直在等待锁，这时候线程B还没有退出synchronize代码块，锁还在线程B手里；
线程B退出synchronize代码块，释放锁之后，线程A和线程C竞争锁；
把上面的代码在Openjdk8下面执行，反复执行多次，都得到以下结果：

thread-A : get lock
thread-A : start wait
thread-B : get lock
thread-C : c thread is start
thread-B : start notify
thread-B : release lock
thread-A : after wait, acquire lock again
thread-A : release lock
thread-C : get lock
thread-C : release lock

针对以上结果，问题来了：
第一个问题：
将以上代码反复执行多次，结果都是B释放锁之后A会先得到锁，这又是为什么呢？C为何不能先拿到锁呢？

第二个问题：
线程C自开始就执行了monitorenter指令，它能得到锁是容易理解的，但是线程A呢？在wait()之后并没有没有monitorenter指令，那么它又是如何取得锁的呢？

wait()、notify()这些方法都是native方法，所以只有从JVM源码寻找答案了，本次阅读的是openjdk8的源码；

带上问题去看JVM源码
按照demo代码执行顺序，我整理了如下问题，带着这些问题去看JVM源码可以聚焦主线，不要被一些支线的次要的代码卡住(例如一些异常处理，监控和上报等)：

线程A在wait()的时候做了什么？
线程C启动后，由于此时线程B持有锁，那么线程C此时在干啥？
线程B在notify()的时候做了什么？
线程B释放锁的时候做了什么？

好了，接下来看源码分析问题吧：

线程A在wait()的时候做了什么

java代码中的

lock.wait();

这个lock是一个object对象

如果你看源码的时候能看到这个是一个native方法,jvm对于native方法的处理有俩种方法,

1. 一种是自定义,使用javah 生成对应的.hpp的头,在用c++写对于的.cpp方法实现,其中会调用jin.h的env方法,在使用gcc编译成.so文件,

ObjTest.java

package jni;
class A {}
public class ObjTest extends A{
    static {
        System.loadLibrary("ObjTest");
    }
    public ObjTest(){
        System.out.println("default");
    }
    public ObjTest(int age){
        System.out.println("param Construtor,age->"+age);
    }
    public native static void test(Object a);

    public static void main(String[] args){
        test(new ObjTest());
    }
}

　　2.另外的一种就是系统自带的native,

如果你要看代码的话

#include <stdio.h>
#include <signal.h>
#include <limits.h>

#include "jni.h"
#include "jni_util.h"
#include "jvm.h"

#include "java_lang_Object.h"

static JNINativeMethod methods[] = {
    {"hashCode",    "()I",                    (void *)&JVM_IHashCode},
    {"wait",        "(J)V",                   (void *)&JVM_MonitorWait},
    {"notify",      "()V",                    (void *)&JVM_MonitorNotify},
    {"notifyAll",   "()V",                    (void *)&JVM_MonitorNotifyAll},
    {"clone",       "()Ljava/lang/Object;",   (void *)&JVM_Clone},
};

JNIEXPORT void JNICALL
Java_java_lang_Object_registerNatives(JNIEnv *env, jclass cls)
{
    (*env)->RegisterNatives(env, cls,
                            methods, sizeof(methods)/sizeof(methods[0]));
}

JNIEXPORT jclass JNICALL
Java_java_lang_Object_getClass(JNIEnv *env, jobject this)
{
    if (this == NULL) {
        JNU_ThrowNullPointerException(env, NULL);
        return 0;
    } else {
        return (*env)->GetObjectClass(env, this);
    }
}

会发现它使用了 RegisterNatives这种方法,wait对于的方法,为   (void *)&JVM_MonitorWait

在share/vm/prims/jvm.cpp文件中定义的

JVM_ENTRY(void, JVM_MonitorWait(JNIEnv* env, jobject handle, jlong ms))
  JVMWrapper("JVM_MonitorWait");
  Handle obj(THREAD, JNIHandles::resolve_non_null(handle));
  JavaThreadInObjectWaitState jtiows(thread, ms != 0);
  if (JvmtiExport::should_post_monitor_wait()) {
    JvmtiExport::post_monitor_wait((JavaThread *)THREAD, (oop)obj(), ms);
  }
  ObjectSynchronizer::wait(obj, ms, CHECK);
JVM_END

重要的是,他要进入ObjectSynchronizer.wait方法

void ObjectSynchronizer::wait(Handle obj, jlong millis, TRAPS) {
    //UseBiasedLocking默认为true
  if (UseBiasedLocking) {
      //撤销对象头中包含的偏向锁
    BiasedLocking::revoke_and_rebias(obj, false, THREAD);
    assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now");
  }
  if (millis < 0) {
    TEVENT (wait - throw IAX) ;
    THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), "timeout value is negative");
  }
    //分配一个关联的ObjectMonitor实例
  ObjectMonitor* monitor = ObjectSynchronizer::inflate(THREAD, obj());
  DTRACE_MONITOR_WAIT_PROBE(monitor, obj(), THREAD, millis);
    //调用其wait方法
  monitor->wait(millis, true, THREAD);

  /* This dummy call is in place to get around dtrace bug 6254741.  Once
     that's fixed we can uncomment the following line and remove the call */
  // DTRACE_MONITOR_PROBE(waited, monitor, obj(), THREAD);
  dtrace_waited_probe(monitor, obj, THREAD);
}

这里就能看到了

//调用其wait方法
monitor->wait(millis, true, THREAD);

线程B在这个时候做了什么

在线程A调用wait方法的同时,线程B也已经启动了,就是jvm源码调试中的Thread-10

能看到这个时候线程B,已经进入了synchronized代码块,其中对应的指令就是monitorenter

对于monitorenter指令进行简单分析

先打印一下bt信息

#0  ObjectMonitor::enter (this=0x7fb1280036e0, __the_thread__=0x7fb11c001800) at /home/atzhang/atzhang/openjdksource/openjdk8/openjdk/hotspot/src/share/vm/runtime/objectMonitor.cpp:323
#1  0x00007fb14a8de3e6 in ObjectSynchronizer::slow_enter (obj=..., lock=0x7fb1345fc6a8, __the_thread__=0x7fb11c001800) at /home/atzhang/atzhang/openjdksource/openjdk8/openjdk/hotspot/src/share/vm/runtime/synchronizer.cpp:258
#2  0x00007fb14a8ddf70 in ObjectSynchronizer::fast_enter (obj=..., lock=0x7fb1345fc6a8, attempt_rebias=true, __the_thread__=0x7fb11c001800) at /home/atzhang/atzhang/openjdksource/openjdk8/openjdk/hotspot/src/share/vm/runtime/synchronizer.cpp:180
#3  0x00007fb14a538e2f in InterpreterRuntime::monitorenter (thread=0x7fb11c001800, elem=0x7fb1345fc6a8) at /home/atzhang/atzhang/openjdksource/openjdk8/openjdk/hotspot/src/share/vm/interpreter/interpreterRuntime.cpp:573

如果看网上的一般文章那么分析的起点就是InterpreterRuntime::monitorenter ,其实是不对的,也就是99.8%的文章都是差了那么一乃乃,

在上下求索的过程中,发现连mashibing的公开课讲的课,黄俊将的synchronized底层实现都是错的,他错在了哪里了? 他用了openjdk1.8早期的

源码版本来讲偏向锁,其实这个源码还没有实现偏向锁,我也遇到了这个问题,发现怎么看也看不懂,那么真正的入口是

bytecodeInterpreter.cpp 

     /* monitorenter and monitorexit for locking/unlocking an object */

      CASE(_monitorenter): {
        oop lockee = STACK_OBJECT(-1);
        // derefing's lockee ought to provoke implicit null check
        CHECK_NULL(lockee);
        // find a free monitor or one already allocated for this object
        // if we find a matching object then we need a new monitor
        // since this is recursive enter
        BasicObjectLock* limit = istate->monitor_base();
        BasicObjectLock* most_recent = (BasicObjectLock*) istate->stack_base();
        BasicObjectLock* entry = NULL;
        while (most_recent != limit ) {
          if (most_recent->obj() == NULL) entry = most_recent;
          else if (most_recent->obj() == lockee) break;
          most_recent++;
        }
        if (entry != NULL) {
          entry->set_obj(lockee);
          int success = false;
          uintptr_t epoch_mask_in_place = (uintptr_t)markOopDesc::epoch_mask_in_place;

          markOop mark = lockee->mark();
          intptr_t hash = (intptr_t) markOopDesc::no_hash;
          // implies UseBiasedLocking
          // code 3：如果锁对象的mark word的状态是偏向模式
          if (mark->has_bias_pattern()) {//has_bias_pattern las 3bit is 101 ?
            uintptr_t thread_ident;
            uintptr_t anticipated_bias_locking_value;
            thread_ident = (uintptr_t)istate->thread();
            anticipated_bias_locking_value =
              (((uintptr_t)lockee->klass()->prototype_header() | thread_ident) ^ (uintptr_t)mark) &
              ~((uintptr_t) markOopDesc::age_mask_in_place);
             // code 5：如果偏向的线程是自己且epoch等于class的epoch
            if  (anticipated_bias_locking_value == 0) {
              // already biased towards this thread, nothing to do
              if (PrintBiasedLockingStatistics) {
                (* BiasedLocking::biased_lock_entry_count_addr())++;
              }
              success = true;
            }
               /**
               *  初始化：偏向锁默认是延时初始化的，延迟的时间通过参数BiasedLockingStartupDelay控制，默认是4000ms默认是4000ms。
               *  初始化是在安全点下通过VMThread完成的，初始化时会把由SystemDictionary维护的所有已加载类的
               *  Klass的prototype_header修改成匿名偏向锁对象头，并把_biased_locking_enabled静态属性置为true，
               *  后续加载新的Klass时发现该属性为true，会将Klass的prototype_header修改成匿名偏向锁对象头。
               *  当创建某个Klass的oop时，会利用Klass的prototype_header来初始化该oop的对象头，即偏向锁初始化完成后，
               *  后续所有创建的oop的初始对象头都是匿名偏向锁的，在此之前创建的oop初始对象头都是无锁状态的。
               */
            else if ((anticipated_bias_locking_value & markOopDesc::biased_lock_mask_in_place) != 0) {
              // try revoke bias

              markOop header = lockee->klass()->prototype_header();
              if (hash != markOopDesc::no_hash) {
                header = header->copy_set_hash(hash);
              }
              //_biased_locking_enabled静态属性为false,默认是4000ms,尚未开启偏向锁,所以撤销偏向锁
              if (Atomic::cmpxchg_ptr(header, lockee->mark_addr(), mark) == mark) {
                if (PrintBiasedLockingStatistics)
                  (*BiasedLocking::revoked_lock_entry_count_addr())++;
              }
            }
             // code 7：如果epoch不等于class中的epoch，则尝试重偏向
            else if ((anticipated_bias_locking_value & epoch_mask_in_place) !=0) {
              // try rebias
              markOop new_header = (markOop) ( (intptr_t) lockee->klass()->prototype_header() | thread_ident);
              if (hash != markOopDesc::no_hash) {
                new_header = new_header->copy_set_hash(hash);
              }
              if (Atomic::cmpxchg_ptr((void*)new_header, lockee->mark_addr(), mark) == mark) {
                if (PrintBiasedLockingStatistics)
                  (* BiasedLocking::rebiased_lock_entry_count_addr())++;
              }
              else {
                // 重偏向失败，代表存在多线程竞争，则调用monitorenter方法进行锁升级
                  CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);
              }
              success = true;
            }
            else {
                // 走到这里说明当前要么偏向别的线程，要么是匿名偏向（即没有偏向任何线程）
                // code 8：下面构建一个匿名偏向的mark word，尝试用CAS指令替换掉锁对象的mark word
                // try to bias towards thread in case object is anonymously biased
              markOop header = (markOop) ((uintptr_t) mark & ((uintptr_t)markOopDesc::biased_lock_mask_in_place |
                                                              (uintptr_t)markOopDesc::age_mask_in_place |
                                                              epoch_mask_in_place));
              if (hash != markOopDesc::no_hash) {
                header = header->copy_set_hash(hash);
              }
              markOop new_header = (markOop) ((uintptr_t) header | thread_ident);
              // debugging hint
              DEBUG_ONLY(entry->lock()->set_displaced_header((markOop) (uintptr_t) 0xdeaddead);)
              if (Atomic::cmpxchg_ptr((void*)new_header, lockee->mark_addr(), header) == header) {
                // CAS修改成功
                  if (PrintBiasedLockingStatistics)
                  (* BiasedLocking::anonymously_biased_lock_entry_count_addr())++;
              }
              else {
                // 如果修改失败说明存在多线程竞争，所以进入monitorenter方法
                CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);
              }
              success = true;
            }
          }
          //if (mark->has_bias_pattern()) {//has_bias_pattern las 3bit is 101 ? } end of code
          //如果没符合的mark->has_bias_pattern就到这里了,
          // traditional lightweight locking
          // 如果偏向线程不是当前线程或没有开启偏向模式等原因都会导致success==false??存疑

          if (!success) {
              // 轻量级锁的逻辑
                //code 9: 构造一个无锁状态的Displaced Mark Word，并将Lock Record的lock指向它
            markOop displaced = lockee->mark()->set_unlocked();
            entry->lock()->set_displaced_header(displaced);
            //如果指定了-XX:+UseHeavyMonitors，则call_vm=true，代表禁用偏向锁和轻量级锁
            bool call_vm = UseHeavyMonitors;
             // 利用CAS将对象头的mark word替换为指向Lock Record的指针,(如果是无锁状态,直接升级轻量级锁)
            if (call_vm || Atomic::cmpxchg_ptr(entry, lockee->mark_addr(), displaced) != displaced) {
              // Is it simple recursive case?
              // 判断是不是锁重入,进入这里说明obj是不是无锁状态,
              if (!call_vm && THREAD->is_lock_owned((address) displaced->clear_lock_bits())) {
                //code 10: 如果是锁重入，则直接将Displaced Mark Word设置为null
                  entry->lock()->set_displaced_header(NULL);
              } else {
                CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);
              }
            }
          }
          UPDATE_PC_AND_TOS_AND_CONTINUE(1, -1);
        } else {
           // lock record不够，重新执行
          istate->set_msg(more_monitors);
          UPDATE_PC_AND_RETURN(0); // Re-execute
        }
      }
      /**
       * JVM中的每个类也有一个类似mark word的prototype_header，用来标记该class的epoch和偏向开关等信息。
       * 上面的代码中lockee->klass()->prototype_header()即获取class的prototype_header。

code 1，从当前线程的栈中找到一个空闲的Lock Record（即代码中的BasicObjectLock，下文都用Lock Record代指），
       判断Lock Record是否空闲的依据是其obj字段 是否为null。
       注意这里是按内存地址从低往高找到最后一个可用的Lock Record，换而言之，就是找到内存地址最高的可用Lock Record。

code 2，获取到Lock Record后，首先要做的就是为其obj字段赋值。

code 3，判断锁对象的mark word是否是偏向模式，即低3位是否为101。

code 4，这里有几步位运算的操作 anticipated_bias_locking_value =
       (((uintptr_t)lockee->klass()->prototype_header() | thread_ident) ^ (uintptr_t)mark) & ​
       ~((uintptr_t) markOopDesc::age_mask_in_place); 这个位运算可以分为3个部分。

第一部分((uintptr_t)lockee->klass()->prototype_header() | thread_ident)
       将当前线程id和类的prototype_header相或，这样得到的值为
       （当前线程id + prototype_header中的（epoch + 分代年龄 + 偏向锁标志 + 锁标志位））
       ，注意prototype_header的分代年龄那4个字节为0

第二部分 ^ (uintptr_t)mark 将上面计算得到的结果与锁对象的markOop进行异或，
       相等的位全部被置为0，只剩下不相等的位。

第三部分 & ~((uintptr_t) markOopDesc::age_mask_in_place) markOopDesc::age_mask_in_place为...0001111000,
       取反后，变成了...1110000111,除了分代年龄那4位，其他位全为1；
       将取反后的结果再与上面的结果相与，将上面异或得到的结果中分代年龄给忽略掉。

code 5，anticipated_bias_locking_value==0代表偏向的线程是当前线程且mark word的epoch等于class的epoch，这种情况下什么都不用做。

code 6，(anticipated_bias_locking_value & markOopDesc::biased_lock_mask_in_place) != 0
       代表class的prototype_header或对象的mark word中偏向模式是关闭的，
       又因为能走到这已经通过了mark->has_bias_pattern()判断，
       即对象的mark word中偏向模式是开启的，那也就是说class的prototype_header不是偏向模式。

然后利用CAS指令Atomic::cmpxchg_ptr(header, lockee->mark_addr(), mark) == mark撤销偏向锁，
       我们知道CAS会有几个参数，1是预期的原值，2是预期修改后的值 ，3是要修改的对象，
       与之对应，cmpxchg_ptr方法第一个参数是预期修改后的值，第2个参数是修改的对象，第3个参数是预期原值，
       方法返回实际原值，如果等于预期原值则说明修改成功。

code 7，如果epoch已过期，则需要重偏向，利用CAS指令将锁对象的mark word替换为一个偏向当前线程且epoch为类的epoch的新的mark word。

code 8，CAS将偏向线程改为当前线程，如果当前是匿名偏向则能修改成功，否则进入锁升级的逻辑。

code 9，这一步已经是轻量级锁的逻辑了。从上图的mark word的格式可以看到，
       轻量级锁中mark word存的是指向Lock Record的指针。这里构造一个无锁状态的mark word，
       然后存储到Lock Record（Lock Record的格式可以看第一篇文章）。设置mark word是无锁状态的原因是：
       轻量级锁解锁时是将对象头的mark word设置为Lock Record中的Displaced Mark Word，
       所以创建时设置为无锁状态，解锁时直接用CAS替换就好了。

code 10， 如果是锁重入，则将Lock Record的Displaced Mark Word设置为null，起到一个锁重入计数的作用。

以上是偏向锁加锁的流程（包括部分轻量级锁的加锁流程），如果当前锁已偏向其他线程||epoch值过期||偏向模式关闭||获取偏向锁的过程中存在并发冲突，
       都会进入到InterpreterRuntime::monitorenter方法， 在该方法中会对偏向锁撤销和升级。
       */

这个比较复杂,如果你下载的版本是hotspot-87ee5ee27509那么你会看到源码为

     /* monitorenter and monitorexit for locking/unlocking an object */

      CASE(_monitorenter): {
        oop lockee = STACK_OBJECT(-1);
        // derefing's lockee ought to provoke implicit null check
        CHECK_NULL(lockee);
        // find a free monitor or one already allocated for this object
        // if we find a matching object then we need a new monitor
        // since this is recursive enter
        BasicObjectLock* limit = istate->monitor_base();
        BasicObjectLock* most_recent = (BasicObjectLock*) istate->stack_base();
        BasicObjectLock* entry = NULL;
        while (most_recent != limit ) {
          if (most_recent->obj() == NULL) entry = most_recent;
          else if (most_recent->obj() == lockee) break;
          most_recent++;
        }
        if (entry != NULL) {
          entry->set_obj(lockee);
          markOop displaced = lockee->mark()->set_unlocked();
          entry->lock()->set_displaced_header(displaced);
          if (Atomic::cmpxchg_ptr(entry, lockee->mark_addr(), displaced) != displaced) {
            // Is it simple recursive case?
            if (THREAD->is_lock_owned((address) displaced->clear_lock_bits())) {
              entry->lock()->set_displaced_header(NULL);
            } else {
              CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);
            }
          }
          UPDATE_PC_AND_TOS_AND_CONTINUE(1, -1);
        } else {
          istate->set_msg(more_monitors);
          UPDATE_PC_AND_RETURN(0); // Re-execute
        }
      }

这个真是个坑,那么分析一下这个过程

接着进入fast_enter

直接进入,

如果进入inflate方法,

会有其中情况:

• // The mark can be in one of the following states:
• // * Inflated - just return
• // * Stack-locked - coerce it to inflated
• // * INFLATING - busy wait for conversion to complete
• // * Neutral - aggressively inflate the object.
• // * BIASED - Illegal. We should never see this
• ===以上是源码注解
• 如果膨胀过了,锁已经是 ObjectMonitor,那么直接返回
• 如果是Stack-locked,就是轻量级锁,那么锁膨胀
• 如果膨胀中
• 如果无锁Neutral,直接膨胀为重量级锁
• 如果biased偏向锁,非法,因为上一个方法有判断,如果是偏向锁,直接返回不会到到达这里的

这里只贴了,锁此刻为重量级锁的时候,

那么返回的 ObjectMonitor * m 进入了enter方法

void ATTR ObjectMonitor::enter(TRAPS) {
  // The following code is ordered to check the most common cases first
  // and to reduce RTS->RTO cache line upgrades on SPARC and IA32 processors.
  Thread * const Self = THREAD ;
  void * cur ;
//原子的设置owner属性，如果_owner属性是NULL就将其设置为Self，否则返回当前的_owner属性
  cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
  if (cur == NULL) {
      //设置成功，说明该Monitor没有被人占用
     // Either ASSERT _recursions == 0 or explicitly set _recursions = 0.
     assert (_recursions == 0   , "invariant") ;
     assert (_owner      == Self, "invariant") ;
     // CONSIDER: set or assert OwnerIsThread == 1
     return ;
  }

  if (cur == Self) {
      //设置失败，说明该Monitor就是当前线程占用的，此处进入enter是嵌套加锁情形
     // TODO-FIXME: check for integer overflow!  BUGID 6557169.
     _recursions ++ ;
     return ;
  }

    //轻量级锁膨胀成重量级锁时，将owner设置为lock属性
  if (Self->is_lock_owned ((address)cur)) {
    assert (_recursions == 0, "internal state error");
    _recursions = 1 ;
    // Commute owner from a thread-specific on-stack BasicLockObject address to
    // a full-fledged "Thread *".
    _owner = Self ;
    OwnerIsThread = 1 ;
    return ;
  }

    //该Monitor被其他某个线程占用了，需要抢占
  // We've encountered genuine contention.
  assert (Self->_Stalled == 0, "invariant") ;

    //记录需要抢占的Monitor指针
  Self->_Stalled = intptr_t(this) ;
  //Knob_SpinEarly默认为1，即为true
    //TrySpin让当前线程自旋，自旋的次数默认可以自适应调整，如果进入安全点同步则退出自旋，返回1表示抢占成功
  // Try one round of spinning *before* enqueueing Self
  // and before going through the awkward and expensive state
  // transitions.  The following spin is strictly optional ...
  // Note that if we acquire the monitor from an initial spin
  // we forgo posting JVMTI events and firing DTRACE probes.
  if (Knob_SpinEarly && TrySpin (Self) > 0) {
     assert (_owner == Self      , "invariant") ;
     assert (_recursions == 0    , "invariant") ;
     assert (((oop)(object()))->mark() == markOopDesc::encode(this), "invariant") ;
     Self->_Stalled = 0 ;
     return ;
  }
//自旋若干次数后依然抢占失败
  assert (_owner != Self          , "invariant") ;
  assert (_succ  != Self          , "invariant") ;
  assert (Self->is_Java_thread()  , "invariant") ;
  JavaThread * jt = (JavaThread *) Self ;
  assert (!SafepointSynchronize::is_at_safepoint(), "invariant") ;
  assert (jt->thread_state() != _thread_blocked   , "invariant") ;
  assert (this->object() != NULL  , "invariant") ;
  assert (_count >= 0, "invariant") ;

  //原子的将_count属性加1，表示增加了一个抢占该锁的线程
  // Prevent deflation at STW-time.  See deflate_idle_monitors() and is_busy().
  // Ensure the object-monitor relationship remains stable while there's contention.
  Atomic::inc_ptr(&_count);

  EventJavaMonitorEnter event;

  { // Change java thread status to indicate blocked on monitor enter.
      //修改Java线程状态为BLOCKED_ON_MONITOR_ENTER，此代码块退出后还原成原来的
    JavaThreadBlockedOnMonitorEnterState jtbmes(jt, this);

    DTRACE_MONITOR_PROBE(contended__enter, this, object(), jt);
    if (JvmtiExport::should_post_monitor_contended_enter()) {
      JvmtiExport::post_monitor_contended_enter(jt, this);
    }

    OSThreadContendState osts(Self->osthread());
    ThreadBlockInVM tbivm(jt);

    Self->set_current_pending_monitor(this);

    // TODO-FIXME: change the following for(;;) loop to straight-line code.
    for (;;) {
      jt->set_suspend_equivalent();
      // cleared by handle_special_suspend_equivalent_condition()
      // or java_suspend_self()
//会通过自旋，park等方式不断循环尝试获取锁，直到成功获取锁为止
      EnterI (THREAD) ;

      if (!ExitSuspendEquivalent(jt)) break ;

      //
      // We have acquired the contended monitor, but while we were
      // waiting another thread suspended us. We don't want to enter
      // the monitor while suspended because that would surprise the
      // thread that suspended us.
      //
          _recursions = 0 ;
      _succ = NULL ;
      exit (false, Self) ;

      jt->java_suspend_self();
    }
    Self->set_current_pending_monitor(NULL);
  }

  Atomic::dec_ptr(&_count);
  assert (_count >= 0, "invariant") ;
  Self->_Stalled = 0 ;

  // Must either set _recursions = 0 or ASSERT _recursions == 0.
  assert (_recursions == 0     , "invariant") ;
  assert (_owner == Self       , "invariant") ;
  assert (_succ  != Self       , "invariant") ;
  assert (((oop)(object()))->mark() == markOopDesc::encode(this), "invariant") ;

  // The thread -- now the owner -- is back in vm mode.
  // Report the glorious news via TI,DTrace and jvmstat.
  // The probe effect is non-trivial.  All the reportage occurs
  // while we hold the monitor, increasing the length of the critical
  // section.  Amdahl's parallel speedup law comes vividly into play.
  //
  // Another option might be to aggregate the events (thread local or
  // per-monitor aggregation) and defer reporting until a more opportune
  // time -- such as next time some thread encounters contention but has
  // yet to acquire the lock.  While spinning that thread could
  // spinning we could increment JVMStat counters, etc.

  DTRACE_MONITOR_PROBE(contended__entered, this, object(), jt);
  if (JvmtiExport::should_post_monitor_contended_entered()) {
    JvmtiExport::post_monitor_contended_entered(jt, this);
  }

  if (event.should_commit()) {
    event.set_klass(((oop)this->object())->klass());
    event.set_previousOwner((TYPE_JAVALANGTHREAD)_previous_owner_tid);
    event.set_address((TYPE_ADDRESS)(uintptr_t)(this->object_addr()));
    event.commit();
  }

  if (ObjectMonitor::_sync_ContendedLockAttempts != NULL) {
     ObjectMonitor::_sync_ContendedLockAttempts->inc() ;
  }
}


// Caveat: TryLock() is not necessarily serializing if it returns failure.
// Callers must compensate as needed.

int ObjectMonitor::TryLock (Thread * Self) {
   for (;;) {
      void * own = _owner ;
      if (own != NULL) return 0 ;
      if (Atomic::cmpxchg_ptr (Self, &_owner, NULL) == NULL) {
         // Either guarantee _recursions == 0 or set _recursions = 0.
         assert (_recursions == 0, "invariant") ;
         assert (_owner == Self, "invariant") ;
         // CONSIDER: set or assert that OwnerIsThread == 1
         return 1 ;
      }
      // The lock had been free momentarily, but we lost the race to the lock.
      // Interference -- the CAS failed.
      // We can either return -1 or retry.
      // Retry doesn't make as much sense because the lock was just acquired.
      if (true) return -1 ;
   }
}

标记了比较重要的方法,主要流程就是

• cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ; cas,期望无人使用锁,(即 MonitorObject._owner为0x0),
• 比如这个时候线程A 会在wati方法在释放锁之前这个_owner的值为ThreadA线程的一个包装对象,那么此时需要等待锁
• 在ThreadA释放锁之后,这个时候如果进入执行这个方法那么,直接回返回,代表已经获取了锁
• 锁进行等待的代码主要是EnterI ,主要实现如下

•     for (;;) {
  
          if (TryLock (Self) > 0) break ;
          assert (_owner != Self, "invariant") ;
  
          if ((SyncFlags & 2) && _Responsible == NULL) {
             Atomic::cmpxchg_ptr (Self, &_Responsible, NULL) ;
          }
  
          // park self
          if (_Responsible == Self || (SyncFlags & 1)) {
              TEVENT (Inflated enter - park TIMED) ;
              Self->_ParkEvent->park ((jlong) RecheckInterval) ;
              // Increase the RecheckInterval, but clamp the value.
              RecheckInterval *= 8 ;
              if (RecheckInterval > 1000) RecheckInterval = 1000 ;
          } else {
              TEVENT (Inflated enter - park UNTIMED) ;
              Self->_ParkEvent->park() ;
          }
  
          if (TryLock(Self) > 0) break ;
  
          // The lock is still contested.
          // Keep a tally of the # of futile wakeups.
          // Note that the counter is not protected by a lock or updated by atomics.
          // That is by design - we trade "lossy" counters which are exposed to
          // races during updates for a lower probe effect.
          TEVENT (Inflated enter - Futile wakeup) ;
          if (ObjectMonitor::_sync_FutileWakeups != NULL) {
             ObjectMonitor::_sync_FutileWakeups->inc() ;
          }
          ++ nWakeups ;
  
          // Assuming this is not a spurious wakeup we'll normally find _succ == Self.
          // We can defer clearing _succ until after the spin completes
          // TrySpin() must tolerate being called with _succ == Self.
          // Try yet another round of adaptive spinning.
          if ((Knob_SpinAfterFutile & 1) && TrySpin (Self) > 0) break ;
  
          // We can find that we were unpark()ed and redesignated _succ while
          // we were spinning.  That's harmless.  If we iterate and call park(),
          // park() will consume the event and return immediately and we'll
          // just spin again.  This pattern can repeat, leaving _succ to simply
          // spin on a CPU.  Enable Knob_ResetEvent to clear pending unparks().
          // Alternately, we can sample fired() here, and if set, forgo spinning
          // in the next iteration.
  
          if ((Knob_ResetEvent & 1) && Self->_ParkEvent->fired()) {
             Self->_ParkEvent->reset() ;
             OrderAccess::fence() ;
          }
          if (_succ == Self) _succ = NULL ;
  
          // Invariant: after clearing _succ a thread *must* retry _owner before parking.
          OrderAccess::fence() ;
      }

  上边的方法里面可以主要看出

  • TryLock(Self),试着cas一把,如果没人占用锁就,占用锁

  • Self->_ParkEvent->park ((jlong) RecheckInterval) ; 线程挂起一段时间

  • 醒了之后,接着TryLock(Self),若不成功则一直循环,

接着看线程A在wait()的时候做了什么

此时线程B在一直循环等待获取锁,线程A开始执行wait方法,2者是并行执行的

可以看到其实Thread9 就是线程A在jvm中对应的线程

那么看到在threadA执行完wait方法之后,先释放了锁.在把自己所对应的linux线程挂起

那么还查threadB.notify分析

流程:

lock.notify()   //调用lock对象的方法

-->                 //这个obj就是这个lock,将lock作为参数

  ObjectSynchronizer::notify(obj, CHECK); 

-->                 //找到obj对象上的重量锁ObjectMonitor 

ObjectSynchronizer::inflate(THREAD, obj())->notify(THREAD);
-->                 // 调用锁上的notify方法

void ObjectMonitor::notify(TRAPS) 

那么现在进入关键步骤

进入的去DequeueWaiter()

接着

 打印

(gdb) p _WaitSet
$1 = (ObjectWaiter * volatile) 0x7f88bbbfa110

(gdb) p *node 
$6 = (ObjectWaiter) {
  <StackObj> = {
    <AllocatedObj> = {
      _vptr.AllocatedObj = 0x7f88d66797f0 <vtable for ObjectWaiter+16>
    }, <No data fields>}, 
  members of ObjectWaiter: 
  _next = 0x7f88bbbfa110, 
  _prev = 0x7f88bbbfa110, 
  _thread = 0x7f88d0160800, 
  _notifier_tid = 140225242177872, 
  _event = 0x7f88d0161b00, 
  _notified = 0, 
  TState = ObjectWaiter::TS_WAIT, 
  _Sorted = (unknown: 3019902016), 
  _active = false
}

看这个链表节点的next和priev都是自己

　　

ObjectWaiter* next = node->_next;   找到下一个节点node3
   if (next == node) {  //如果next指向自己说明,只有一个node节点,那么久就将_WaitSet置空
　　assert(node->_prev == node, "invariant check");
　　_WaitSet = NULL;
　} else {    //不进入这里,这里是中间节点的情况
　　ObjectWaiter* prev = node->_prev;  找到上一个节点 ,命名node1

　　next->_prev = prev;    令下一个节点的上一个指向 node1
　　prev->_next = next;     令node1的_next指针指向node3
　　if (_WaitSet == node) {    
　　_WaitSet = next;
　　　　}
　　}
　　node->_next = NULL; 接着道这里,将node节点的next ,priev置空
　　node->_prev = NULL;

这就

那么这样就取出来了objectWaiter 对象

接下来对ObjectWaiter对象的处理方式，根据Policy的不同而不同：
Policy == 0：放入_EntryList队列的排头位置；
Policy == 1：放入_EntryList队列的末尾位置；
Policy == 2：_EntryList队列为空就放入_EntryList，否则放入_cxq队列的排头位置；

那么接着进入ThreadB的monitorexit指令

小结一下，线程B释放了锁之后，执行的操作如下：

偏向锁逻辑，此处未命中；
根据QMode的不同，将ObjectWaiter从_cxq或者_EntryList中取出后唤醒；
唤醒的元素会继续执行挂起前的代码，按照我们之前的分析，线程唤醒后，就会通过CAS去竞争锁，此时由于线程B已经释放了锁，那么此时应该能竞争成功；

唤醒目标线程,就是A之前wait方法里面挂起了,那么接着看wait方法的实现

还有

//ReenterI和EnterI的逻辑基本相同，用于获取对象锁
void ATTR ObjectMonitor::ReenterI (Thread * Self, ObjectWaiter * SelfNode) {
    assert (Self != NULL                , "invariant") ;
    assert (SelfNode != NULL            , "invariant") ;
    assert (SelfNode->_thread == Self   , "invariant") ;
    assert (_waiters > 0                , "invariant") ;
    //校验目标对象的对象头就是当前ObjectMonitor的指针
    assert (((oop)(object()))->mark() == markOopDesc::encode(this) , "invariant") ;
    assert (((JavaThread *)Self)->thread_state() != _thread_blocked, "invariant") ;
    JavaThread * jt = (JavaThread *) Self ;
 
    int nWakeups = 0 ;
    for (;;) {
        ObjectWaiter::TStates v = SelfNode->TState ;
        //校验状态
        guarantee (v == ObjectWaiter::TS_ENTER || v == ObjectWaiter::TS_CXQ, "invariant") ;
        assert    (_owner != Self, "invariant") ;
        
        //尝试获取锁
        if (TryLock (Self) > 0) break ;
        //尝试自旋获取锁
        if (TrySpin (Self) > 0) break ;
 
        TEVENT (Wait Reentry - parking) ;
 
        {   
           //修改线程状态
           OSThreadContendState osts(Self->osthread());
           ThreadBlockInVM tbivm(jt);
 
           jt->set_suspend_equivalent();
           //SyncFlags默认是0
           if (SyncFlags & 1) {
              Self->_ParkEvent->park ((jlong)1000) ;
           } else {
              Self->_ParkEvent->park () ;
           }
 
           // were we externally suspended while we were waiting?
           for (;;) {
              //ExitSuspendEquivalent默认返回false
              if (!ExitSuspendEquivalent (jt)) break ;
              if (_succ == Self) { _succ = NULL; OrderAccess::fence(); }
              jt->java_suspend_self();
              jt->set_suspend_equivalent();
           }
        }
 
        //尝试获取锁
        if (TryLock(Self) > 0) break ;
 
        TEVENT (Wait Reentry - futile wakeup) ;
        ++ nWakeups ;
 
        // Assuming this is not a spurious wakeup we'll normally
        // find that _succ == Self.
        if (_succ == Self) _succ = NULL ;
 
        // Invariant: after clearing _succ a contending thread
        // *must* retry  _owner before parking.
        OrderAccess::fence() ;
 
        if (ObjectMonitor::_sync_FutileWakeups != NULL) {
          ObjectMonitor::_sync_FutileWakeups->inc() ;
        }
    }//for循环结束
 
    //for循环结束，已经获取了锁
    assert (_owner == Self, "invariant") ;
    assert (((oop)(object()))->mark() == markOopDesc::encode(this), "invariant") ;
    //从链表中移除
    UnlinkAfterAcquire (Self, SelfNode) ;
    if (_succ == Self) _succ = NULL ;
    assert (_succ != Self, "invariant") ;
    //修改状态为TS_RUN
    SelfNode->TState = ObjectWaiter::TS_RUN ;
    OrderAccess::fence() ;      // see comments at the end of EnterI()
}

本文结束