JUC并发编程共享模型之管程（三）(中)
4.5Monitor概念
Java 对象头
以 32 位虚拟机为例（在32位虚拟机中，1个机器码等于4字节，也就是32bit，在64位虚拟机中，1个机器码是8个字节，也就是64bit）
普通对象
数组对象
其中Mark Word 结构为 ： 最后两位是锁标志位
64位虚拟机 Mark Word
原理之 Monitor(锁)
Monitor 被翻译为 监视器 或 管程
每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的 Mark Word 中就被设置指向 Monitor 对象的指针
结构：
- 刚开始 Monitor 中 Owner 为null
- 当Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为Thread-2，Monitor中只能有有一个人Owner
- 在Thread-2上锁过程中，如果Thread-3，Thread-4，Thread-5也来执行 synchronized(obj) ，就会进入EntryList BLOCKED
- Thread-2执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，竞争是非公平的
- 图中WaitSet中的Thread-0，Thread-1是之前获得过锁，但条件不满足进入WAITING状态的线程。
注意：
synchronized 必须是进入同一个对象的 monitor 才有上述的效果
不加 synchronized 的对象不会关联监视器，不遵从以上规则
4.6 原理synchronized
static final Object lock = new Object();
static int counter = 0;
public static void main(String[] args) {
synchronized (lock) {
counter++;
}
}
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=3, args_size=1
0: getstatic #2 // <- lock引用 （synchronized开始）
3: dup
4: astore_1 // lock引用 -> slot 1
5: monitorenter // 将 lock对象 MarkWord 置为 Monitor 指针
6: getstatic #3 // <- i
9: iconst_1 // 准备常数 1
10: iadd // +1
11: putstatic #3 // -> i
14: aload_1 // <- lock引用
15: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
16: goto 24
19: astore_2 // e -> slot 2
20: aload_1 // <- lock引用
21: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
22: aload_2 // <- slot 2 (e)
23: athrow // throw e
24: return
Exception table:
from to target type
6 16 19 any
19 22 19 any
LineNumberTable:
line 8: 0
line 9: 6
line 10: 14
line 11: 24
LocalVariableTable:
Start Length Slot Name Signature
0 25 0 args [Ljava/lang/String;
StackMapTable: number_of_entries = 2
frame_type = 255 /* full_frame */
offset_delta = 19
locals = [ class "[Ljava/lang/String;", class java/lang/Object ]
stack = [ class java/lang/Throwable ]
frame_type = 250 /* chop */
offset_delta = 4
注意 方法级别的 synchronized 不会在字节码指令中有所体现
4.7 synchronize 锁
轻量级锁
轻量级锁的使用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以用轻量级锁来优化。
轻量级锁对使用者是透明的，即语法仍然是 synchronized
假设有两个方法同步块，利用同一个对象加锁
static final Object obj = new Object();
public static void method1() {
synchronized( obj ) {
// 同步块 A
method2();
}
}
public static void method2() {
synchronized( obj ) {
// 同步块 B
}
}
-
创建锁记录(Lock Record) 对象，让每个线程的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的 Mark Word
-
让锁记录中 Object reference 指向锁对象，并尝试用 cas 替换 Object 的 Mark Word，将 Mark Word 的值存 入锁记录
-
如果 cas 替换成功，对象头中存储了 锁记录地址和状态 00 ，表示由该线程给对象加锁
-
如果 cas 失败，有两种情况
- 如果是其他线程已经持有了该Object的轻量级锁，这是表明有竞争，进入锁膨胀过程（这里先不讨论，锁膨胀再说）
- 如果是自己执行了synchronized锁重入，那么再添加一条Lock Record作为重入的计数
-
当退出 synchronized 代码块(解锁时) 如果有取值为null的锁记录，表示有锁重入，这时重置锁记录，表示重入计数-1
-
当退出 synchronized 代码块(解锁时) 所记录的值不为null，这时使用cas将 Mark Word 的值恢复给对象头
- 成功，则解锁成功
- 失败，则说明轻量级锁进入了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程
锁膨胀
如果在尝试加轻量级锁的过程中，CAS操作无法成功，这时有一种情况就是有其他线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁
static Object obj = new Object();
public static void method1() {
synchronized( obj ) {
// 同步块
}
}
-
当Thread-1进行轻量级加锁时，Thread-0已经对该对象加了轻量级锁
-
这是Thread-1加轻量级锁失败，进入了锁膨胀流程
- 即为Object对象申请Monitor锁，让Object指向重量级锁地址
- 然后自己进入Monitor的EntryList BLOCKED
-
当Thread-0退出同步块解锁时，使用CAS将Mark Word的值恢复给对象头，失败，这时会进入重量级解锁流程，即按照Monitor地址找到Monitor对象，设置Owner为null，唤醒EntryList中BLOCKED线程
自旋优化
重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步 块，释放了锁），这时当前线程就可以避免阻塞
自旋重试成功的情况：
自旋重试失败的情况：
- 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
- 在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会 高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。
- Java 7 之后不能控制是否开启自旋功能
偏向锁
- 轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行CAS操作
- Java6中引入偏向锁来做进一步优化：只有第一次使用CAS将线程ID设置到对象的Mark Word头，之后发现这个线程ID是自己的就表示没有竞争，不用重新CAS。以后只要不发生竞争，这个对象就归线程所有
static final Object obj = new Object();
public static void m1() {
synchronized( obj ) {
// 同步块 A
m2();
}
}
public static void m2() {
synchronized( obj ) {
// 同步块 B
m3();
}
}
public static void m3() {
synchronized( obj ) {
// 同步块 C
}
}
偏向状态
对象头格式
一个对象创建时：
- 如果开启了偏向锁（默认开启），那么对象创建后，Mark Word 值为0x05即最后3位为101，这时它的thread、epoch、age都为0
- 偏向锁默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加个VM参数 -XX:BisasedLockingStartupDelay=0 来禁用延迟
- 如果没有开启偏向锁，那么对象创建后，Mark Word值为0x01 即最后3位为001，这时它的hashcode、age都为0，第一次用到 hashcode 时才会赋值
撤销偏向锁
使用hashcode()方法
调用了对象的hashCode，但偏向锁的对象Mark Word 中存储的是线程id，如果调用hashCode 会导致偏向锁被撤销
- 轻量级锁会在所记录中记录 hashCode
- 重量级锁会在 Monitor 中记录 hashCode
在调用 hashCode 后使用偏向锁，记得去掉 -XX:-UseBiasedLocking
其它线程使用对象
当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁
用 wait/notify
一个线程在加锁之前先wait。另一个线程先使用锁，等待锁用完之后，调用notify唤醒正在wait的线程，使得两个线程分开始用锁，在第二个线程使用锁前的时候，先是偏向第一个线程的(101)，在使用锁的时偏向锁就失效了，转化为了000（轻量级锁），使用锁之后，输出的最后三位是001(偏向锁失效的状态，即正常状态)
批量重偏向
- 如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象 的 Thread ID
- 当撤销偏向锁阈值超过 20 次后，jvm 会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至 加锁线程
批量撤销
当撤销偏向锁阈值超过 40 次后，jvm 会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象 都会变为不可偏向的，新建的对象也是不可偏向的
锁消除
锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。