虚拟机中对象锁实现分析

原创 Victor Cheng OPPO内核工匠

一、前言

编程过程中经常会遇到线程的同步问题，Java 中对同步问题的解决方案比较多（synchronized、JUC、原子操作、volatile、条件变量等），其中synchronized 最方便、简单易用，也是java 编程中使用最多的临界区保护方案。本文主要讲述对象锁的相关知识，详细介绍synchronized 和Object 的关键方法的虚拟机实现原理。

二、Java 对象锁的使用方式

2.1 实例方法的同步

synchronized 修饰实例方法，该同步仅对当前对象的该方法起作用，同一时间只能有一个线程可以进入该对象的此方法。对于不同对象的此函数，无法做到互斥保护。

2.2 静态方法的同步

synchronized 修饰静态方法，该同步对当前类对象的该方法起作用，同一时间只能有一个线程可以进入该方法。

2.3 代码块的同步

在大多少情况下，并不需要对整个方法进行保护，当synchronized 修饰代码块时，该代码块的访问依赖于object 对象锁的互斥访问，同一时间只能有一个线程持有object 对象锁。

更准确的来讲，synchronized 关键字是依赖于对象锁而生效的，每个synchronized 同步块开始的地方都会生成monitor-enter obj指令，同步块结束的地方生成monitor-exit obj 的指令，其中obj 为用于控制互斥访问的对象。同一时间只能有一个线程持有obj 的对象锁。在2.1 中synchronized 依赖的是实列对象，2.2 中synchronized 依赖的是类对象，2.3 中synchronized 依赖的是object 对象。

当一个对象控制多个代码块时，多个代码块也是互斥访问，如下面代码：

代码块①和代码块② 虽然在两个函数中，但是synchronized 依赖的对象都为object，这两个代码块也是互斥访问。

2.4 Object wait() 和notify() 使用方法

Object 作为所有类的基类，都实现了object方法。典型的用法如下：

thread 1持有object 对象锁，并调用object.wait() 方法后，则该线程进入WAITING状态，并释放object 对象锁，等待其它线程来唤醒它。

当thread 2 持有object 对象锁，并调用object.notify()方法后，唤醒thread 1，thread 1

重新获得object 对象锁继续执行。Object类方法说明：

三、Android对象内存结构

3.1 对象内存结构

一个类的实例对象内存主要由3部分组成：

1). 对象头：对象头包括kclass_和monitor_两个字段，其中kclass_ 存放指向类对象的指针，通过该指针可以找到该对象对应的类，monitor_ 用于存放对象运行时的标识数据，例如: GC 标志位、哈希码、锁状态等信息,后面详细分析。

2). 实例数据，该部分存放实例变量值，父类实例变量值在前，子类在后，且实例变量值按照如下顺序进行排序：

3).对齐填充，对象在内存中是按照8byte 对齐的，如果实例数据部分没有按照8byte对齐，则填充为8byte 对齐。

3.2 monitor_ 字段分析

monitor_ 字段定义在art/runtime/mirror/object.h，类型为uint32_t，主要有下面3个操作函数。

操作函数中SetLockWord和CasLockWord函数的入参或GetLockWord函数的返回值都包含LockWord 变量，对monitor_ 字段的操作是通过LockWord 的值进行的。

下面再来看LockWord 定义：

LockWord 类的定义在art/runtime/lock_word.h 文件中，从注释中可以看到LockWord的使用主要有4种状态，如下：

LockWord 的设计非常精妙，一个32 位数据的每一位都充分利用，而且很好的区分了不同状态。下面对各状态进行详细说明：

unlocked/thin 状态下31-30 bit 为00，默认状态下为unlocked 状态，当对象进行线程同步时变成thin lock 状态，27-16bit 记录了thin lock重入的次数，15-0 bit 记录了持有该thin lock的线程ID。
fat lock状态下31-30 bit 为01，当对象锁在thin lock状态，且有新的(非owner)线程与其竞争，经过适当的等待期（sched_yield调用、循环获取thin lock 状态）后依然无法拿到锁，则转换为fat lock 状态，并为该对象分配一个Monitor 资源。
hash state状态下31-30 bit 为10，在27-0 bit 存储对象的hash code，当在其它模式下，hash code 会存储在该对象关联的Monitor 对象中。
forwarding address state 状态下31-30 bit 为11，在concurrent copying GC 的copy 阶段，当一个对象被拷贝后，指向拷贝后的对象地址，当线程访问到该对象后，通过该转发地址，访问新的对象。

第29 位为mark bit，通过该bit位可以快速判断是否标记过，避免重复标记。

第28 位为read barrier bit，如果对象LockWorkd的该bit 被设置，则在访问该对象的成员时会进入慢速路径，判断对象是不是需要更新，如果需要更新，则返回拷贝后的对象地址。

四、对象锁代码分析

4.1 首先我们看一段代码

这段代码比较简单，主要有下面两个核心点：

1). 在主线程执行的过程中，用obj 对象进行线程同步，并调用obj.wait()函数，使线程阻塞在了obj 对象锁上等待唤醒。

2). main函数中创建匿名线程，该线程首先sleep 2000ms，然后唤醒阻塞在obj 对象锁上线程。

4.2编译TestDemo.java,命令如下：

1).Javac 将TestDemo.java 文件编译生成TestDemo*.class文件,java 编译过程中每个类会生成一个class 文件。

2).d8 命令将TestDemo*.class 文件通过编译、重构、重排、压缩、混淆后生成对应的dex （Dalvik Executable file）格式文件。

3).dexdump.exe命令可以查看dex 文件格式的详细信息，如校验信息、dex 头信息、生成dex 的CFG 信息、dex 的反汇编信息等，详细使用方法可以通过dexdump.exe –help 命令查看

通过dexdump.exe –d classes.dex 查看反汇编

其中run 方法指令信息如下：

main 函数的指令信息如下：

对部分指令解析如下:

对于dex 指令详细格式可以阅读google 的官方文档：

https://source.android.com/docs/core/runtime/dalvik-bytecode

本文重点分析monitor-enter、monitor-exit、Object.wait()、Object.notify()在虚拟机中的详细实现。

4.3．Object.wait() 流程分析

Object.wait() 的调用关系如下：

Object 类是所有类的父类，任何类中都可以调用public 的wait() 方法，最终调用到虚拟机的monitor.cc 文件的wait 静态方法，

首先构造了一个操作obj 的Handle对象h_obj，通过ObjectWaitStart 函数通知jvmti 调试系统发生了JVMTI_EVENT_MONITOR_WAIT 事件。

JVMTI（JVM Tool Interface）是 Java 虚拟机所提供的 native 编程接口，可以用来开发并监控虚拟机，可以查看JVM内部的状态，并控制JVM应用程序的执行。可实现的功能包括但不限于：调试、监控、线程分析、覆盖率分析工具等。

首先获得h_obj 对象的LockWord 字段，lock_word.GetState()函数获得当前的锁状态，主要有下面几种情况：

1).hash 或unlocked 状态:

因为调用wait()方法必须持有对象锁，所以不会出现这两种状态，如果出现则抛出IllegalMonitorStateException 异常。

2).thin lock 状态：

当持有该对象锁的线程不是要wait 的线程，也抛出IllegalMonitorStateException 异常，当持有锁的线程与要wait 的线程一致，这时需要将thin lock inflate 为fat lock，inflate 的过程在monitor-enter 指令分析中分析。

当对象锁inflate 为fat lock 状态后，调用Monitor 对象的实例方法Wait让线程进入sleep 状态等待。

4.4 Object.notify() 流程分析

这里我们直接分析DoNotify 函数：

通过lock_word.GetState() 获得当前obj 对象的锁状态，主要有下面情况：

1) hash 或unlocked 状态 :

抛出IllegalMonitorStateException 异常。

2).thin lock 状态：

当持有该对象锁的线程不是要notify 的线程，也抛出IllegalMonitorStateException 异常，当持有锁的线程与要notify 的线程一致，这时说明没有需要通知唤醒的线程，直接返回。

3).fat lock 状态：

在Object.notify() 流程中参数notify_all 为false，则直接调用mon->Notify(self);通知唤醒等待线程。

4.5monitor-enter 流程分析

对于解释执行和机器码执行模式，最终都会调用到art/runtime/mirror/object-inl.h 文件Object 对象的MonitorEnter 函数。

下面来分析Monitor类的静态方法MonitorEnter 函数。

FakeLock 主要用于线程安全性检查，主要在编译期检测。

kExtraSpinIters 定义了当对象锁被其它线程持有且为thin lock 时，竞争线程循环获取锁的次数。

通过lock_word.GetState() 获取锁状态，当锁状态为unlocked 状态时，转换为thin lock 状态，并通过cas 操作更新lock count。

当锁状态为thin lock 状态时，首先获取锁的owner 线程id，如果owner id 与竞争线程id 一致，则有下面两种情况：

如果lock count加1小于等于(1<<12)-1(4095)时，将lock count+1 更新lock count。
如果lock count加1大于(1<<12)-1时(lock count 区域无法存储)，则调用InflateThinLocked 函数对thin lock 进行膨胀。

Atrace* 相关的函数主要用于systrace 相关信息的打印，trylock 在这里为false。

当锁状态为thin lock 状态且锁的owner 线程id 与竞争线程id 不一致，则做一定的等待。

runtime->GetMaxSpinsBeforeThinLockInflation() 的值为50 ，也就是说执行100 次的循环判断锁状态后，再执行50次的sched_yield() 后还未获得锁资源，如果还未拿到锁，则对该锁进行膨胀。sched_yield() 会主动让出当前线程的执行权限，并在某个时间后恢复执行。

当锁状态已经是fat lock 状态，通过lock_word.FatLockMonitor(); 获取Monitor 对象，并通过Monitor 对象的Lock 函数让线程进入等待状态。

当锁状态已经是hash 状态时，直接对锁进行膨胀。

下面看锁膨胀的过程：

thin lock 的膨胀有两种情形：

1).lock count 的值超过了4095，这时锁的owner 为当前线程，即直接通过Inflate 函数膨胀

2).锁的owner不是当前线程，通过SuspendThreadByThreadId 暂停锁的owner 线程（主要是owner 线程和锁膨胀线程都需要访问对象的LockWord，避免竞态问题），然后通过Inflate 进行膨胀。膨胀完成后再唤醒锁的owner 线程。

再看Inflate 的过程：

通过MonitorPool::CreateMonitor函数获取一个Monitor 的对象m，并通过m->install(self)函数更新对象的LockWord字段，这时LockWord 字段信息包含fat lock 状态、GC 状态、MonitorId，然后将m 保存在monitor_list_ 中。

monitor_list_中存储了当前虚拟机使用的所有Monitor 对象。在GC 的过程中，通过该链表，访问到Monitor 依赖的对象。如果对象变成垃圾对象，则回收该Monitor，否则更新Monitor 依赖的对象信息。

MonitorId 用于唯一标识一个Monitor，生成的方法可以看monitor_pool.h 中的实现。

再看Monitor::Lock的过程：

该函数的实现较长，省去调试相关的代码。