4.5 Monitor 概念
4.5.1 java对象头
-
以 32 位虚拟机为例
-
普通对象
|--------------------------------------------------------------| | Object Header (64 bits) | |------------------------------------|-------------------------| | Mark Word (32 bits) | Klass Word (32 bits) | |------------------------------------|-------------------------|
Klass Word (32 bits) :指向class类型
-
数组对象
|---------------------------------------------------------------------------------| | Object Header (96 bits) | |--------------------------------|-----------------------|------------------------| | Mark Word(32bits) | Klass Word(32bits) | array length(32bits) | |--------------------------------|-----------------------|------------------------|
-
其中 Mark Word 结构为
|-------------------------------------------------------|--------------------| | Mark Word (32 bits) | State | |-------------------------------------------------------|--------------------| | hashcode:25 | age:4 | biased_lock:0 | 01 | Normal | |-------------------------------------------------------|--------------------| | thread:23 | epoch:2 | age:4 | biased_lock:1 | 01 | Biased | |-------------------------------------------------------|--------------------| | ptr_to_lock_record:30 | 00 | Lightweight Locked | |-------------------------------------------------------|--------------------| | ptr_to_heavyweight_monitor:30 | 10 | Heavyweight Locked | |-------------------------------------------------------|--------------------| | | 11 | Marked for GC | |-------------------------------------------------------|--------------------|
-
-
64位虚拟机 Mark Word
|--------------------------------------------------------------------|--------------------| | Mark Word (64 bits) | State | |--------------------------------------------------------------------|--------------------| | unused:25 | hashcode:31 | unused:1 | age:4 | biased_lock:0 | 01 | Normal | |--------------------------------------------------------------------|--------------------| | thread:54 | epoch:2 | unused:1 | age:4 | biased_lock:1 | 01 | Biased | |--------------------------------------------------------------------|--------------------| | ptr_to_lock_record:62 | 00 | Lightweight Locked | |--------------------------------------------------------------------|--------------------| | ptr_to_heavyweight_monitor:62 | 10 | Heavyweight Locked | |--------------------------------------------------------------------|--------------------| | | 11 | Marked for GC | |--------------------------------------------------------------------|--------------------|
4.5.2 原理之Monitor
Monitor 被翻译为监视器或管程
每个 Java 对象都可以关联一个 Monitor 对象,如果使用 synchronized 给对象上锁(重量级)之后,该对象头的 Mark Word 中就被设置指向 Monitor 对象的指针
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 状态的线程,后面讲 wait-notify 时会分析
synchroize 必须是同一对象的Monitor,才会如上
不加synchroize 的对象不会关联监视器,不会如上
4.5.3 Monitor原理之synchronize
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
4.5.4 原理之synchronize 进阶
4.5.4.1 小故事
- 老王 - JVM
- 小南 - 线程
- 小女 - 线程
- 房间 - 对象
- 房间门上 - 防盗锁- Monitor
- 房间门上 -小南书包 - 轻量级锁
- 房间门上 - 刻上小南大名 - 偏向锁
- 批量重刻名 - 一个类的偏向锁撤销达到20阈值
- 不能刻名字 - 批量撤销该类对象的偏向锁,设置该类不可偏向
小南要使用房间保证计算不被其它人干扰(原子性),最初,他用的是防盗锁,当上下文切换时,锁住门。这样,即使他离开了,别人也进不了门,他的工作就是安全的。
但是,很多情况下没人跟他来竞争房间的使用权。小女是要用房间,但使用的时间上是错开的,小南白天用,小女晚上用。每次上锁太麻烦了,有没有更简单的办法呢?
小南和小女商量了一下,约定不锁门了,而是谁用房间,谁把自己的书包挂在门口,但他们的书包样式都一样,因此每次进门前得翻翻书包,看课本是谁的,如果是自己的,那么就可以进门,这样省的上锁解锁了。万一书包不是自己的,那么就在门外等,并通知对方下次用锁门的方式。
后来,小女回老家了,很长一段时间都不会用这个房间。小南每次还是挂书包,翻书包,虽然比锁门省事了,但仍然觉得麻烦。于是,小南干脆在门上刻上了自己的名字:【小南专属房间,其它人勿用】,下次来用房间时,只要名字还在,那么说明没人打扰,还是可以安全地使用房间。如果这期间有其它人要用这个房间,那么由使用者将小南刻的名字擦掉,升级为挂书包的方式。
同学们都放假回老家了,小南就膨胀了,在20个房间刻上了自己的名字,想进哪个进哪个。后来他自己放假回老家了,这时小女回来了(她也要用这些房间),结果就是得一个个地擦掉小南刻的名字,升级为挂书包的方式。老王觉得这成本有点高,提出了一种批量重刻名的方法,他让小女不用挂书包了,可以直接在门上刻上自己的名字
后来,刻名的现象越来越频繁,老王受不了了:算了,这些房间都不能刻名了,只能挂书包
4.5.4.2 轻量级锁
轻量级锁的使用场景:如果一个对象虽然有多线程要加锁,但加锁的时间是错开的(也就是没有竞争),那么可以 使用轻量级锁来优化。
轻量级锁对使用者是透明的,即语法仍然是
synchronized
假设有两个方法同步块,利用同一个对象加锁
static final Object lock = new Object();
public static void method1() {
synchronized( lock ) {
// 同步块 A
method2();
}
}
public static void method2() {
synchronized( lock ) {
// 同步块 B
}
}
- method1 执行到synchronized( lock ) 创建锁记录(Lock Record)对象的,每个线程的栈帧都会包含一个锁记录的结构,内部可以存储锁定对象的Mark Word
- 让锁记录的对象指针(Object reference)指向锁对象,并尝试用 cas 替换 Object 的 Mark Word ,将Mark Word的值存入锁记录(01 表示无锁状态 [01 还有偏向锁状态] 、00 轻量级锁状态)
- 如果 cas 替换成功 ,对象头中存储了
锁记录的地址 和状态 00
,表示由改线程给对象加锁了
-
如果cas 失败了 则有2种情况
-
如果其他线程已经持有以了该Object的轻量级锁,这时表明有锁竞争,进入锁膨胀的过程(可看锁膨胀图解)
-
如果是自己执行了synchronize锁重入(method2 执行到synchronized( lock ) ),那么再添加一条lock Record作为重入的计数
-
当退出synchronize 代码块(解锁时)如果有取值为null的锁记录,表示有重入,这时重置锁记录,表示重入计数-1 (减去一条lock record)
-
当退出synchronize 代码块(解锁时)锁记录的值不为null,这时使用cas讲Mark Word 的值恢复给对象头
- 成功 : 解锁成功
- 失败:说明轻量级锁进行了锁膨胀或者已经升级为重量级锁,进入重量级锁流程
-
4.5.4.3 锁膨胀
如果在尝试加轻量级锁的过程中,cas 操作无法成功吗, 这时一种情况就是有其它线程为此对象加上了轻量级锁,这时有了锁竞争,将会从轻量级锁变为重量级锁
代码如下:
static Object obj = new Object();
public static void method1() {
synchronized( obj ) {
// 同步块
}
}
-
当Thread-1 进行了轻量级加锁时,Thread -0 已经堆该对象加了轻量级锁
-
这时Thread -1 加轻量级锁失败,进入锁膨胀流程
-
为Object对象申请Monitor锁,让Object指向重量级锁地址(01 表示无锁状态 [01 还有偏向锁状态]、00 轻量级锁状态、10 重量级锁)
-
当前线程进入Monitor的EntryList BLOCKED
-
-
当Thread -0 退出同步快解锁时,使用cas 将mark word 的值恢复给对象头,失败。这时候就会进入重量级锁解锁流程,按照Monitor地址找到Monitor对象,设置Owner为null,唤醒EntryList中BLOCKED线程
4.5.4.3 自旋优化
重量级锁竞争的时候,还可以使用自旋来进行优化,如果当前线程自旋成功,(这时候锁线程已经退出同步块,释放了锁),这时当前线程就可以避免阻塞
自旋重试成功的情况
线程1(cpu 1 ) | 对象 Mark Word | 线程2 (cpu 上) |
---|---|---|
- | 10(重量级锁) | - |
访问同步块,获取Monitor | 10(重量级锁)重量锁指针 | - |
成功(加锁) | 10(重量级锁)重量锁指针 | - |
执行同步块 | 10(重量级锁)重量锁指针 | - |
执行同步块 | 10(重量级锁)重量锁指针 | 访问同步块,获取monitor |
执行同步块 | 10(重量级锁)重量锁指针 | 自旋重试 |
执行完毕 | 10(重量级锁)重量锁指针 | 自旋重试 |
成功(解锁) | 01 无锁 | 自旋重试 |
- | 10(重量级锁)重量锁指针 | 成功(加锁) |
- | 10(重量级锁)重量锁指针 | 执行同步块 |
…… | …… | …… |
自旋重试失败的情况
线程1(cpu 1 ) | 对象 Mark Word | 线程2 (cpu 上) |
---|---|---|
- | 10(重量级锁) | - |
访问同步块,获取Monitor | 10(重量级锁)重量锁指针 | - |
成功(加锁) | 10(重量级锁)重量锁指针 | - |
执行同步块 | 10(重量级锁)重量锁指针 | - |
执行同步块 | 10(重量级锁)重量锁指针 | 访问同步块,获取monitor |
执行同步块 | 10(重量级锁)重量锁指针 | 自旋重试 |
执行同步块 | 10(重量级锁)重量锁指针 | 自旋重试 |
执行同步块 | 10(重量级锁)重量锁指针 | 自旋重试 |
…… | …… | …… |
- java 6 以后自旋是自适应,jvm 底层控制,成功过的,会多自旋几次,反之少几次
- 自旋回占用cpu时间,单核cpu自旋就是浪费,多核cpu自旋才能发挥优势
- java 7 以后不能控制是否开启自旋功能
4.5.4.4 偏向锁
轻量级锁在没有竞争时(就自己这个线程),每次重入仍然需要执行CAS操作,比较消耗性能
Java 6中引入了偏向锁来做进一步优化:只有 第一次使用CAS将线程ID设置到对象的Mark Word头,之后发现 这个线程ID是自己的就表示没有竞争,不用重新CAS。以后只要不发生竞争,这个对象就归该线程所有
4.5.4.4.1 偏向锁状态
-
开启了偏向锁,那么对象创建后, mark word 值为 0x05 即后三位为101 ,这时他的thread 、epoch、age 都为0
-
偏向锁默认是延迟的,不会在程序启动时立即生效,如果想避免延迟,可以添加JVM参数
-XX:BiasedLockingStartupDelay=0
来禁用延迟 -
如果没有开启偏向锁,mark word 的 植为0x01 即后3位001 ,这时他的thread 、epoch、age 都为0 ,第一次用到hsahcode时才会赋值
4.5.4.4.2偏向锁撤销
-
撤销- HashCode
调用了对象的 hashCode,但偏向锁的对象 MarkWord 中存储的是线程 id,如果调用 hashCode 会导致偏向锁被撤销(对象头64位不能同时存hashCode 和 线程id)
- 轻量级锁会在锁记录中记录 hashCode
- 重量级锁会在 Monitor 中记录 hashCode
在调用 hashCode 后使用偏向锁,记得去掉 -XX:-UseBiasedLocking
-
撤销- 其他线程使用对象
当有其它线程使用偏向锁对象时,会将偏向锁升级为轻量级锁
-
撤销 - 调用 wait/notify
当前线程必须拥有此对象额monitor(锁)【重量级锁才会用到monitor】,才能调用某个对象的wait()方法让当前线程阻塞
4.5.4.4.3偏向锁撤销
如果对象虽然被多个线程访问,但没有竞争,这时偏向了线程 T1 的对象仍有机会重新偏向 T2,重偏向会重置对象的 Thread ID
当撤销偏向锁阈值为第 20 次时,jvm 会这样觉得,我是不是偏向错了呢,于是会在给这些对象加锁时重新偏向至加锁线程
4.5.4.4.4 偏向锁批量撤销
当撤销偏向锁阈值为第 40 次时,jvm 会这样觉得,自己确实偏向错了,根本就不该偏向。于是整个类的所有对象都会变为不可偏向的,新建的对象也是不可偏向的
4.6 锁消除
锁消除是指虚拟机 (JIT)即时编译器 在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行削除。锁削除的主要判定依据来源于逃逸分析的数据支持,如果判断到一段代码中,在堆上的所有数据都不会逃逸出去被其他线程访问到,那就可以把它们当作栈上数据对待,认为它们是线程私有的,同步加锁自然就无须进行。
4.7锁粗化
对相同对象多次加锁,导致线程发生多次重入,可以使用锁粗化方式来优化,这不同于之前讲的细分锁的粒度。
5.wait /notify
- Owent线程发现条件不满足,调用wait方法,使线程进入WaitSet 变为WAITING状态
- BLOCKED 和WAITING 的现场都处于阻塞状态,不占用cpu时间片
- BLOCKED 线程会在Owenr线程释放锁时被唤醒
- WAITING线程会在Owner线程调用notify 或notifyAll时唤醒,但唤醒后并不意味着立刻获得锁,需进入EntryList重新竞争锁
5.1 API介绍
obj.wait()
让进入 object 监视器的线程到 waitSet 等待(必须获得锁才能调用,不然会报异常)- wait() 方法会释放对象的锁,进入 WaitSet 等待区,从而让其他线程就机会获取对象的锁。无限制等待,直到notify 为止
- wait(long n) 有时限的等待, 到 n 毫秒后结束等待,或是被 notify
obj.notify()
在 object 上正在 waitSet 等待的线程中挑一个唤醒obj.notifyAll()
让 object 上正在 waitSet 等待的线程全部唤醒
6、 wait 、notify 使用
6.1 sleep(long)和wait(long)的区别和共同点
-
区别
-
sleep 是 Thread 方法,而 wait 是 Object 的方法
-
sleep 不需要强制和 synchronized 配合使用,但 wait 需要和 synchronized 一起用
-
sleep 在睡眠的同时,不会释放对象锁的,但 wait 在等待的时候会释放对象锁
-
-
共同点
- 它们状态 TIMED_WAITING
本文为学习笔记
By:黑马程序员全面深入学习Java并发编程,JUC并发编程全套教程