《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile(一)

简介: 《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile

一、Monitor 原理


Monitor 被翻译为监视器或管程

每个 Java 对象都可以关联一个 Monitor 对象(可以将Monitor对象看成锁对象),如果使用 synchronized 给对象上锁(重量级)之后,该对象头的Mark Word 中就被设置指向 Monitor 对象的指针。如图所示:


5b77163f18982eb8501de392bb5633f4.png


多线程执行时,Monitor 结构变化如下:


4ddbf3f48e3cd66cedf6e8855884900e.png


刚开始 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. (执行synchronized(obj)前,会先检查monitor是否有owner,如果有了,则该线程进入EntryList)

Thread-2 执行完同步代码块的内容,然后唤醒 EntryList 中等待的线程来竞争锁,竞争的时是非公平的

图中 WaitSet 中的 Thread-0,Thread-1 是之前获得过锁,但条件不满足进入 WAITING 状态的线程,后面讲wait-notify 时会分析

注意:


synchronized 必须是进入同一个对象的 monitor 才有上述的效果

不加 synchronized 的对象不会关联监视器,不遵从以上规则


二、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          // 将lock引用复制一份
        4: astore_1 // lock引用 -> slot 1; 将lock引用赋给 局部变量表的slot[1]
        5: monitorenter // 将 lock对象 MarkWord 置为 Monitor 指针
        //以下四行是counter++的操作;
        6: getstatic #3 //  获取counter的值
        9: iconst_1 // 准备常数 ,保存counter
       10: iadd //  常数进行+1
       11: putstatic #3 // 将常数写回counter中
       14: aload_1 // 获得lock引用,进行解锁
       15: monitorexit // 将 lock对象的 MarkWord 重置, 唤醒 EntryList (退出Monitor)
       16: goto 24 // 跳转到24 退出
       19: astore_2 // e -> slot 2  将异常对象保存到slot[2]中
       20: aload_1 // 获得lock引用,进行解锁
       21: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList(退出Monitor)
       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 不会在字节码指令中有所体现

三、synchronized 原理进阶

0. 小故事


故事角色

老王 - JVM

小南 - 线程

小女 - 线程

房间 - 对象

房间门上 - 防盗锁 - Monitor

房间门上 - 小南书包 - 轻量级锁

房间门上 - 刻上小南大名 - 偏向锁

批量重刻名 - 一个类的偏向锁撤销到达 20 阈值

不能刻名字 - 批量撤销该类对象的偏向锁,设置该类不可偏向

小南要使用房间保证计算不被其它人干扰(原子性),最初,他用的是防盗锁(Monitor),当上下文切换时,锁住门。这样,即使他离开了,别人也进不了门,他的工作就是安全的。— 重量级锁


但是,很多情况下没人跟他来竞争房间的使用权。小女是要用房间,但使用的时间上是错开的,小南白天用,小女晚上用。每次上锁太麻烦了,有没有更简单的办法呢?— 挂书包(轻量级锁)


小南和小女商量了一下,约定不锁门了,而是谁用房间,谁把自己的书包挂在门口,但他们的书包样式都一样,因此每次进门前得翻翻书包,看课本是谁的,如果是自己的,那么就可以进门,这样省的上锁解锁了。万一书包不是自己的,那么就在门外等,并通知对方下次用锁门的方式(存在竞争时,锁升级,轻量级 --> 重量级)。


后来,小女回老家了,很长一段时间都不会用这个房间。小南每次还是挂书包,翻书包,虽然比锁门省事了,但仍然觉得麻烦。


于是,小南干脆在门上刻上了自己的名字:【小南专属房间,其它人勿用】,(偏向锁)下次来用房间时,只要名字还在,那么说明没人打扰,还是可以安全地使用房间。如果这期间有其它人要用这个房间,那么由使用者将小南刻的名字擦掉,升级为挂书包的方式。(存在竞争时,锁升级,偏向锁 --> 轻量级锁)


同学们都放假回老家了,小南就膨胀了,在 20 个房间刻上了自己的名字,想进哪个进哪个。后来他自己放假回老家了,这时小女回来了(她也要用这些房间),结果就是得一个个地擦掉小南刻的名字,升级为挂书包的方式。老王(JVM)觉得这成本有点高,提出了一种批量重刻名的方法,他让小女不用挂书包了,可以直接在门上刻上自己的名字(批量重偏向)


后来,刻名的现象越来越频繁,老王受不了了:算了,这些房间都不能刻名了,只能挂书包(不可偏向)


1. 轻量级锁


==轻量级锁的使用场景:==如果一个对象虽然有多线程要加锁,但加锁的时间是错开的(也就是没有竞争),那么可以使用轻量级锁来优化。 (如果后续加锁失败了,则换用 重量级锁加锁)


轻量级锁对使用者是透明的,即语法仍然是 synchronized

假设有两个方法同步块,利用同一个对象加锁

static final Object obj = new Object();
public static void method1() {
    synchronized( obj ) {
        // 同步块 A
        method2();
    }
}
public static void method2() {
    synchronized( obj ) {
    // 同步块 B
    }
}


创建锁记录(Lock Record)对象,每个线程的栈帧都会包含一个锁记录的结构,内部可以存储锁定对象的MarkWord (对应着lock recode)


b9d83ee23b33bc543de14571410391c5.png


让锁记录中 Object reference 指向锁对象,并尝试用 cas(反转替换操作) 替换 Object 的 Mark Word,将 Mark Word 的值存入锁记录


7b2665811f6443b487452949ee3c6f1b.png


如果 cas 替换成功,对象头中存储了锁记录地址和状态 00 ,表示由该线程给对象加锁,这时图示如下


9828f32320ba342061e7c75db34f8cba.png


如果 cas 失败,有两种情况

如果是其它线程已经持有了该 Object 的轻量级锁(锁对象对应着 00 ),这时表明有竞争,进入锁膨胀过程

如果是自己执行了 synchronized 锁重入,那么再添加一条 Lock Record 作为重入的计数 (Lock Record有几个,对应着有几层锁)。例:上面代码中method1中调用method2


2412dd2fbe0c26d1292aec54bb12e4cd.png


当退出 synchronized 代码块(解锁时)如果有取值为 null 的锁记录,表示有重入,这时重置锁记录,表示重入计数减一


1547c6e1b903a3adbbc3b61a6dc10aec.png


当退出 synchronized 代码块(解锁时)锁记录的值不为 null,这时使用 cas 将 Mark Word 的值恢复给对象头

成功,则解锁成功

失败,说明轻量级锁进行了锁膨胀或已经升级为重量级锁,进入重量级锁解锁流程


2. 锁膨胀

如果在尝试加轻量级锁的过程中,CAS 操作无法成功,这时一种情况就是有其它线程为此对象加上了轻量级锁(有竞争),这时需要进行锁膨胀,将轻量级锁变为重量级锁。

static Object obj = new Object();
public static void method1() {
    synchronized( obj ) {
    // 同步块
    }
}

当Thread-1 进行轻量级加锁时,Thread-0 已经对该对象加了轻量级锁


55955c04fe87eb57257ae48011beefdb.png


这时 Thread-1 加轻量级锁失败,进入锁膨胀流程

即为 Object 对象申请 Monitor 锁,让 Object 指向重量级锁地址

然后自己进入 Monitor 的 EntryList ,状态变为BLOCKED


dd9a837728eaad6bbc836099e849e531.png


**注意:**因为线程优先是加轻量级锁的,但是锁对象已经被Thread-0 加上了轻量级锁,Thread-1 再次加锁失败。轻量级锁没有等待序列,所以进入锁膨胀,创建重量级锁,Thread-1 进入等待序列。


当 Thread-0 退出同步块解锁时,使用 cas 将 Mark Word 的值恢复给对象头,失败 ( 因为锁对象此时加的是重量级锁)。这时会进入重量级解锁流程,即按照 Monitor 地址找到 Monitor 对象,设置 Owner 为 null,唤醒 EntryList 中 的 BLOCKED 线程。让这些线程进行非公平竞争。


3. 自旋优化


重量级锁竞争的时候,还可以使用自旋来进行优化,如果当前线程自旋成功(即这时候持锁线程已经退出了同步块,释放了锁),这时当前线程就可以避免阻塞。

优点:子旋优化 不会马上让当前线程进入等待状态,而是进行自旋重试操作,如果自旋成功,就不需要进行上下文切换,优化了性能

自旋重试成功的情况


image.png


自旋重试失败的情况


image.png


自旋会占用 CPU 时间,单核 CPU 自旋就是浪费,多核 CPU 自旋才能发挥优势。

在 Java 6 之后自旋锁是自适应的,比如对象刚刚的一次自旋操作成功过,那么认为这次自旋成功的可能性会

高,就多自旋几次;反之,就少自旋甚至不自旋,总之,比较智能。

Java 7 之后不能控制是否开启自旋功能


4. 偏向锁


轻量级锁在没有竞争时(就自己这个线程),每次重入仍然需要执行 CAS 操作。(锁重入:当前线程对同一对象多次加锁)


Java 6 中引入了偏向锁来做进一步优化:只有第一次使用 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
    }
}

如果使用轻量级锁,第一次会让锁记录 替换锁对象的 makeword字段。之后每一次锁重入时,都会用锁记录尝试替换锁对象的makeword,但是这些cas替换都会失败 。从而造成资源浪费和性能损耗!


699671ecad20ef3fd5b3e7712a3e3017.png


使用偏向锁优化:第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头,之后发现这个线程 ID 是自己的就表示没有竞争,不用重新 CAS。


5dc54f5ac6c4bede30252fbfeacf26ff.png

4.1 偏向状态

回忆一下对象头格式

|--------------------------------------------------------------------|--------------------|
|                         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   |
|--------------------------------------------------------------------|--------------------|



相关文章
|
监控 安全
并发编程系列教程(06) - 多线程之间通讯(wait、notify、sleep、Lock锁、Condition)
并发编程系列教程(06) - 多线程之间通讯(wait、notify、sleep、Lock锁、Condition)
68 0
|
4月前
|
存储 SQL 安全
Java共享问题 、synchronized 线程安全分析、Monitor、wait/notify以及锁分类
Java共享问题 、synchronized 线程安全分析、Monitor、wait/notify以及锁分类
45 0
|
4月前
|
Java
Java中的线程通信:wait、notify与Condition详解
Java中的线程通信:wait、notify与Condition详解
|
Java C语言 C++
JUC--start线程
native:本地方法栈,c语言的函数,但凡调用的是这个接口,就是调用底层操作系统,第三方c语言的接口。 也就是说多线程和语言无关,是操作系统层面的东西。基本上每种语言都有自己的多线程实现方式。
|
Java
高并发编程-Wait Set 多线程的“休息室”
高并发编程-Wait Set 多线程的“休息室”
71 0
|
安全 Java C++
JUC在深入面试题——三种方式实现线程等待和唤醒(wait/notify,await/signal,LockSupport的park/unpark)
JUC在深入面试题——三种方式实现线程等待和唤醒(wait/notify,await/signal,LockSupport的park/unpark)
218 1
JUC在深入面试题——三种方式实现线程等待和唤醒(wait/notify,await/signal,LockSupport的park/unpark)
|
缓存 索引
《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile(三)
《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile
《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile(三)
|
存储 Java 编译器
《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile(二)
《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile
《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile(二)
《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile(四)
《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile
《JUC并发编程 - 原理篇》Monitor | synchronized | wait&notify | join | park&unpark | 指令级并行 | volatile(四)
《JUC并发编程 - 高级篇》03 - 共享对象之管程 下篇(Monitor | wait&notify | Park&Unpark | 线程状态转换 | 活跃性 | ReentrantLock)(二)
《JUC并发编程 - 高级篇》03 - 共享对象之管程 下篇(Monitor | wait&notify | Park&Unpark | 线程状态转换 | 活跃性 | ReentrantLock)
《JUC并发编程 - 高级篇》03 - 共享对象之管程 下篇(Monitor | wait&notify | Park&Unpark | 线程状态转换 | 活跃性 | ReentrantLock)(二)