多线程学习十七:synchronized锁升级过程

最新推荐文章于 2024-04-01 15:42:05 发布

老冰糖啊

最新推荐文章于 2024-04-01 15:42:05 发布

阅读量149

点赞数

文章标签： synchronized

本文链接：https://blog.csdn.net/LHBGXX/article/details/115327519

版权

Monitor 概念

在了解Monitor 之前我们首先来了解Java 对象头
以 32 位虚拟机为例

普通对象
在这里插入图片描述

数组对象
在这里插入图片描述

其中 Mark Word 结构为
在这里插入图片描述
Monitor ：被翻译为监视器或管程,每个 Java 对象都可以关联一个 Monitor 对象，如果使用synchronized给对象上锁（重量级）之后，该对象头的MarkWord中就被设置指向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 时会分析

轻量级锁:

轻量级锁的使用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。轻量级锁对使用者是透明的，即语法仍然是 synchronized.

轻量级锁加锁过程：线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录(Lock Record)的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。

1.创建锁记录:
在这里插入图片描述
2.让锁记录中Object reference指向锁对象，并尝试用cas替换 Object 的 MarkWord，将Mark Word的值存入锁记录(Lock Record),然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。

如果 cas 替换成功，对象头中存储了锁记录地址和状态 00 ，表示由该线程给对象加锁，这时图示如下
在这里插入图片描述
如果 cas 失败，有两种情况：

如果是其它线程已经持有了该Object的轻量级锁,这时表明有竞争,进入锁膨胀过程(锁升级)
如果是自己执行了 synchronized锁重入，那么再添加一条Lock Record作为重入的计数，如图所示

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

当拥有轻量级锁的线程退出 synchronized 代码块（解锁时）锁记录的值不为 null，这时使用cas将Mark Word的值恢复给对象头
成功，则解锁成功
失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

重量级锁/锁膨胀(锁升级):

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

如图当 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 操作。Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程ID是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有
在这里插入图片描述

偏向状态:

一个对象创建时：

如果开启了偏向锁（默认开启），那么对象创建后，markword 值为 0x05 即最后 3 位为 101，这时它的thread、epoch、age 都为 0

偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数XX:BiasedLockingStartupDelay=0 来禁用延迟,测试代码如下

11:08:58.117 c.TestBiased [t1] - synchronized 前
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101 偏向锁开启101，thread、epoch、age 都为 0
11:08:58.121 c.TestBiased [t1] - synchronized 中
00000000 00000000 00000000 00000000 00011111 11101011 11010000 00000101 偏向锁加锁中threadId、epoch、age不为空
11:08:58.121 c.TestBiased [t1] - synchronized 后
00000000 00000000 00000000 00000000 00011111 11101011 11010000 00000101 处于偏向锁的对象解锁后，thread、epoch、age仍存储于对象头中

如果没有开启偏向锁（通过:-XX:-UseBiasedLocking设置关闭），那么对象创建后，markword 值为 0x01 即最后 3 位为 001（无锁），这时它的hashcode、age 都为 0，第一次用到 hashcode 时才会赋值，如果对对象加锁，会直接变为轻量级锁。释放完之后还是无锁状态，测试代码如下：

11:13:10.018 c.TestBiased [t1] - synchronized 前
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 无锁 hashcode、age 都为 0
11:13:10.021 c.TestBiased [t1] - synchronized 中
00000000 00000000 00000000 00000000 00100000 00010100 11110011 10001000 轻量级锁 hashcode、age有值
11:13:10.021 c.TestBiased [t1] - synchronized 后
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001  无锁 hashcode、age 都为 0

注意：

如果禁用偏向锁，对象在正常状态对象一开始是没有 hashCode 的，处于无锁状态，第一次调用才生成hashcode
调用了对象的 hashCode，但偏向锁的对象 MarkWord 中存储的是线程 id，如果调用 hashCode 会导致偏向锁被撤销,让线程处于无锁状态（存储hashcode、age，是否偏向锁状态），如果此时要加锁，线程会加轻量级锁（存储指向栈中锁记录的指针），锁用完之后还会处于无锁状态（存储hashcode、age，是否偏向锁状态），
轻量级锁会在锁记录中记录 hashCode,重量级锁会在 Monitor 中记录 hashCode

撤销 - 其它线程使用对象

当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁测试代码如下：

//t1线程未加锁前，线程处于偏向锁，但不存储threadId、epoch、age所以未0
[t1] - 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101 
//t1线程加加锁时，线程处于偏向锁，存储threadId、epoch、age的值
[t1] - 00000000 00000000 00000000 00000000 00011111 01000001 00010000 00000101 
//t1线程释放完锁t2执行，线程处于偏向锁，存储t1的threadId、epoch、age的值
[t2] - 00000000 00000000 00000000 00000000 00011111 01000001 00010000 00000101
//t2会将线程升级未轻量级锁 并存储指向栈中锁记录的指针
[t2] - 00000000 00000000 00000000 00000000 00011111 10110101 11110000 01000000
//t2执行完成之后线程处于无锁状态hashcode、age 都为 0
[t2] - 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

撤销 - 调用 wait/notify

调用wait/notify会将对象的偏向锁升级为重量级锁

批量重偏向

批量重偏向：如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象的 Thread ID，当撤销偏向锁阈值超过20次后，jvm 会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至加锁线程，测试代码如下：

private static void test3() throws InterruptedException {
 	Vector<Dog> list = new Vector<>();
 	Thread t1 = new Thread(() -> {
 	for (int i = 0; i < 30; i++) {
  		Dog d = new Dog();
     	list.add(d);
     	synchronized (d) {
  	   		//t2会等待t1执行完再运行，所以这段时间内只有t1在用，因此这段时间内一直是偏向锁
  	   		log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
     	}
	 }
     synchronized (list) {
     	list.notify();
     } 
     }, "t1");
 	t1.start();
 
     Thread t2 = new Thread(() -> {
     synchronized (list) {
     try {
     list.wait();
     } catch (InterruptedException e) {
     e.printStackTrace();
     }
     }
     log.debug("===============> ");
     for (int i = 0; i < 30; i++) {
     	Dog d = list.get(i);
     	log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
     	synchronized (d) {
     		log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
     	}
     	log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
     }
     }, "t2");
     t2.start();
}
运行结果：
[t1] - 0 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 1 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
..........此处省略部分结果，我们可以看到t1一直处于偏向锁状态
[t1] - 28 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 29 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - ===============> 
//t2拿到锁时处于偏向锁，锁偏向于t1，因为t1刚执行完
[t2] - 0 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101
//不符合偏向锁的规则，t2将他升级未轻量级锁
[t2] - 0 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
//t2执行完成之后，会将轻量级锁置为无锁状态
[t2] - 0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
........
[t2] - 18 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 18 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 18 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001
//当t2执行完20次之后 虚拟机认为自己偏向错了，改为偏向t2,此后锁偏向与t2
[t2] - 19 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 19 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 19 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
.........
[t2] - 29 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 29 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 29 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101

批量撤销

**批量撤销:**当撤销偏向锁阈值超过 40 次后，jvm 会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的,处于无锁状态001

public class Test26 {
    static Thread t1,t2,t3;
    private static void test4() throws InterruptedException {
        Vector<Dog> list = new Vector<>();
        int loopNumber = 39;
        t1 = new Thread(() -> {
            for (int i = 0; i < loopNumber; i++) {
                Dog d = new Dog();
                list.add(d);
                synchronized (d) {
                    log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
                }
            }
            LockSupport.unpark(t2);
        }, "t1");
        t1.start();
        t2 = new Thread(() -> {
            LockSupport.park();
            log.debug("===============> ");
            for (int i = 0; i < loopNumber; i++) {
                Dog d = list.get(i);
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
                synchronized (d) {
                    log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
                }
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
            }
            LockSupport.unpark(t3);
        }, "t2");
        t2.start();
        t3 = new Thread(() -> {
            LockSupport.park();
            log.debug("===============> ");
            for (int i = 0; i < loopNumber; i++) {
                Dog d = list.get(i);
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
                synchronized (d) {
                    log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
                }
                log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
            }
        }, "t3");
        t3.start();
        t3.join();
        log.debug(ClassLayout.parseInstance(new Dog()).toPrintableSimple(true));
    }
}

老冰糖啊

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
多线程学习十七:synchronized锁升级过程

Monitor 概念在了解Monitor 之前我们首先来了解Java 对象头以 32 位虚拟机为例普通对象数组对象其中 Mark Word 结构为Monitor ：被翻译为监视器或管程,每个 Java 对象都可以关联一个 Monitor 对象，如果使用synchronized给对象上锁（重量级）之后，该对象头的MarkWord中就被设置指向Monitor对象的指针(Monitor 是操作系统层面的)分析：刚开始 Monitor 中 Owner 为 null，当 Thread-2 执行
复制链接

扫一扫