JUC并发编程共享模型之管程（三）(中)

晓风残月Lx

已于 2023-03-09 11:37:30 修改

阅读量146

点赞数

于 2023-03-08 23:24:22 首次发布

本文链接：https://blog.csdn.net/m0_55993923/article/details/129413632

版权

JUC 专栏收录该内容

16 篇文章 0 订阅

订阅专栏

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 会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的

锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。

晓风残月Lx

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
JUC并发编程共享模型之管程（三）(中)

JUC并发编程共享模型之管程，本文包含内容有Monitor、Java对象头、轻量级锁、重量级锁、锁膨胀、偏向锁、批量重偏向、锁消除知识点，对synchronized的原理和synchronized锁进行了详细的说明
复制链接

扫一扫