1 Monitor Obejct模式
- Monitor Obejct模式综述
- Monitor其实是一种同步工具，也可以说是一种同步机制，它通常被描述为一个对象，主要特点是互斥和信号机制
- 互斥： 一个Monitor锁在同一时刻只能被一个线程占用，其他线程无法占用
- 信号机制(signal)： 占用Monitor锁失败的线程会暂时放弃竞争并等待某个谓词成真（条件变量），但该条件成立后，当前线程会通过释放锁通知正在等待这个条件变量的其他线程，让其可以重新竞争锁
- Mesa派的signal机制
- Mesa派的signal机制又称"Non-Blocking condition variable"
- 占有Monitor锁的线程发出释放通知时，不会立即失去锁，而是让其他线程等待在队列中，重新竞争锁
- 这种机制里，等待者拿到锁后不能确定在这个时间差里是否有别的等待者进入过Monitor，因此不能保证谓词一定为真，所以对条件的判断必须使用while
- Java中采用就是Mesa派的singal机制，即所谓的notify
Monitor Obejct模式协作过程
在 Monitor Object 模式中，主要有四种类型的参与者：
1.png
- 1.同步方法的调用和串行化：
当客户线程调用监视者对象的同步方法时，必须首先获取它的监视锁
只要该监视者对象有其他同步方法正在被执行，获取操作便不会成功
当监视者对象已被线程占用时(即同步方法正被执行)，客户线程将被阻塞直到它获取监视锁
当客户线程成功获取监视锁后，进入临界区，执行方法实现的服务
一旦同步方法完成执行，监视锁会被自动释放，目的是使其他客户线程有机会调用执行该监视者对象的同步方法- 2.同步方法线程挂起：如果调用同步方法的客户线程必须被阻塞或是有其他原因不能立刻进行，它能够在一个监视条件(Monitor Condition)上等待，这将导致该客户线程暂时释放监视锁，并被挂起在监视条件上
- 3.监视条件通知：一个客户线程能够通知一个监视条件，目的是通知阻塞在该监视条件(该监视锁)的线程恢复运行
- 4.同步方法线程恢复：
一旦一个早先被挂起在监视条件上的同步方法线程获取通知，它将继续在最初的等待监视条件的点上执行
在被通知线程被允许恢复执行同步方法之前，监视锁将自动被获取(线程间自动相互竞争锁)
对于Monitor笔者将在 并发番@ReentractLock一文通中进一步阐述
2 对象头
JVM内存中的对象
- 在JVM中，对象在内存中的布局分成三块区域：对象头、示例数据和对齐填充
- 对象头： 对象头主要存储对象的hashCode、锁信息、类型指针、数组长度(若是数组的话)等信息
- 示例数据：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组长度，这部分内存按4字节对齐
- 填充数据：由于JVM要求对象起始地址必须是8字节的整数倍，当不满足8字节时会自动填充（因此填充数据并不是必须的，仅仅是为了字节对齐）
对象头综述
2.png
- synchcronized的锁是存放在Java对象头中的
- 如果对象是数组类型，JVM用3个子宽(Word)存储对象头，否则是用2个子宽
- 在32位虚拟机中，1子宽等于4个字节，即32bit；64位的话就是8个字节，即64bit
Mark Word的存储结构
32位JVM的Mark Word的默认存储结构（无锁状态）
3.png
在运行期间，Mark Word里存储的数据会随着锁标志位的变化而变化(32位)
4.png
64位JVM的Mark Word的默认存储结构(对于32位无锁状态，有25bit没有使用)
5.png
3 Monitor Record
- MonitorRecord(统一简称MR)是Java线程私有的数据结构，每一个线程都有一个可用MR列表，同时还有一个全局的可用列表
- 一个被锁住的对象都会和一个MR关联（对象头的MarkWord中的LockWord指向MR的起始地址）
- MR中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用
Monitor Record结构
6.png
Monitor Record工作机理
- 线程如果获得监视锁成功，将成为该监视锁对象的拥有者
- 在任一时刻，监视器对象只属于一个活动线程(Owner)
- 拥有者可以调用wait方法自动释放监视锁，进入等待状态
7.png
参考
并发番@Synchronized一文通（1.8版）