【JUC】 Synchronized与锁升级

最新推荐文章于 2024-09-13 21:40:38 发布

Hello Dam

最新推荐文章于 2024-09-13 21:40:38 发布

阅读量613

点赞数 26

分类专栏： # JUC Java开发文章标签： JUC java 开发语言 Synchronized

本文链接：https://blog.csdn.net/laodanqiu/article/details/141091378

版权

Java开发同时被 2 个专栏收录

136 篇文章 13 订阅

订阅专栏

JUC

16 篇文章 1 订阅

订阅专栏

面试题

谈谈你对Synchronized的理解
Synchronized的锁升级你聊聊
Synchronized实现原理，monitor对象什么时候生成的？知道monitor的monitorenter和monitorexit这两个是怎么保证同步的嘛？或者说这两个操作计算机底层是如何执行的
偏向锁和轻量级锁有什么区别

阿里加锁规范

【强制】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，不要锁整个方法体；能用对象锁，就不要用类锁。

说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC方法。

用锁能够实现数据的安全性，但是会带来性能下降。
无锁能够基于线程并行提升程序性能，但是安全性下降。

如何在性能和安全之间求平衡？？？

Synchronized的性能变化背景

Java5以前，只有Synchronized，这个是操作系统级别的重量级操作
- 重量级锁，假如锁的竞争比较激烈的话，性能下降
- 牵扯到用户态和内核态之间的转换，性能较差

在这里插入图片描述

Mutex Lock：Monitor是在jvm底层实现的，底层代码是c++。本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的转换，状态转换需要耗费很多的处理器时间成本非常高。所以synchronized是Java语言中的一个重量级操作。

Monitor与java对象以及线程是如何关联？

1、如果一个java对象被某个线程锁住，则该java对象的Mark Word字段中LockWord指向monitor的起始地址

2、Monitor的Owner字段会存放拥有相关联对象锁的线程id

Mutex Lock的切换需要从用户态转换到核心态中，因此状态转换需要耗费很多的处理器时间。

在这里插入图片描述

Java6 之后为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁

Synchronized锁种类及升级步骤

多线程访问情况

只有一个线程来访问，有且仅有一个
两个线程交替访问
竞争激烈，很多线程来访问

升级流程

在这里插入图片描述

Synchronized用的锁是存在Java对象头里的MarkWord中，锁升级功能主要依赖MarkWord中锁标志位和释放偏向锁标志位
64位标记图

在这里插入图片描述

锁指向，请牢记（参照上图理解）
- 偏向锁：MarkWord存储的是偏向的线程ID
- 轻量锁：MarkWord存储的是指向线程栈中Lock Record的指针
- 重量锁：MarkWord存储的是指向堆中的monitor对象（系统互斥量指针）

无锁

Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable());

在这里插入图片描述

为什么上面的hashcode位都是0呢？一个对象，如果还没有调用hashcode方法，是不会有hashcode的

private static void noLock() {
    Object o = new Object();

    System.out.println("10进制：" + o.hashCode());
    System.out.println("16进制：" + Integer.toHexString(o.hashCode()));
    System.out.println("2进制：" + Integer.toBinaryString(o.hashCode()));

    //2进制：1001010010101110100011110010101
    //      1001010010101110100011110010101
    System.out.println(ClassLayout.parseInstance(o).toPrintable());
}

调用hashcode方法之后，再输出对象头信息，就会发现hashcode里面有非零数字了

在这里插入图片描述

0（补位的，不用看）1001010 01010111 01000111 10010101（图上的信息倒着看）

偏向锁

偏向锁：单线程竞争，当线程A第一次竞争到锁时，通过修改MarkWord中的偏向线程ID、偏向模式。如果不存在其他线程竞争，那么持有偏向锁的线程将永远不需要进行同步。（每次访问锁的都是同一个线程，不需要反复加锁、解锁，不进行用户态、内核态频繁的切换）

在这里插入图片描述

主要作用

当一段同步代码一直被同一个线程多次访问，由于只有一个线程那么该线程在后续访问时便会自动获得锁

结论

HotSpot的作者经过研究发现，大多数情况下：在多线程情况下，锁不仅不存在多线程竞争，还存在由同一个线程多次获得的情况，偏向锁就是在这种情况下出现的，它的出现是为了解决只有一个线程执行同步时提高性能。
偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他线程访问，则持有偏向锁的线程将永远不需要触发同步。也即偏向锁在资源在没有竞争情况下消除了同步语句，懒得连CAS操作都不做了，直接提高程序性能。

理论落地

在实际应用运行过程中发现，“锁总是同一个线程持有，很少发生竞争”，也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。那么只需要在锁第一次被拥有的时候，记录下偏向线程D。这样偏向线程就一直持有着锁（后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接会去检查锁的MarkWord里面是不是放的自己的线程ID)。

如果相等，表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到有其他线程竞争发生才释放锁。以后每次同步，检查锁的偏向线程ID与当前线程ID是否一致，如果一致直接进入同步块。无需每次加锁解锁都去CAS更新对象头。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
如果不等，表示发生了竞争，锁已经不是总是偏向于同一个线程了，这个时候会尝试使用CAS来替换MarkWord里面的线程ID为新线程的ID，
- 竞争成功，表示之前的线程不存在了，MarkWord里面的线程ID修改为新线程的ID，锁不会升级，仍然为偏向锁（线程A执行完成，线程B进来，获得锁）
- 竞争失败，这时候可能需要升级变为轻量级锁，才能保证线程间公平竞争锁。（线程A没有结束，线程B一直自旋抢锁）

注意，偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。

技术实现

一个synchronized方法被一个线程抢到了锁时，那这个方法所在的对象就会在其所在的Mark Word中将偏向锁修改状态位，同时还会有占用前54位来存储线程指针作为标识。若该线程再次访问同一个synchronized方法时，该线程只需去对象头的Mark Word中去判断一下是否有偏向锁指向本身的ID，无需再进入Monitor去竞争对象了。

在这里插入图片描述

偏向锁JVM命令

java -XX:+PrintFlagsInitial |grep BiasedLock*：将偏向锁相关的参数打印出来

在这里插入图片描述

实际上偏向锁在JDK1.6之后是默认开启的，但是启动时间有延迟，需要添加参数-XX：BiasedLockingStartupDeLay=0，让其在程序启动时立刻启动。
开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
关闭偏向锁：关闭之后程序默认会直接进入轻量级锁状态，-XX:-UseBiasedLocking

案例演示

偏向锁默认情况演示—只有一个线程

private static void biasedLock() {
    Object o = new Object();
    System.out.println(ClassLayout.parseInstance(o).toPrintable());
    new Thread(() -> {
        synchronized (o) {
            System.out.println(ClassLayout.parseInstance(o).toPrintable());
        }
    }, "t1").start();
}

设置延迟为0（也可以线程休眠超过4秒），保存偏向锁启动成功

在这里插入图片描述

无线程使用锁

private static void biasedLock() {
    //先睡眠5秒，保证开启偏向锁
    try {
        TimeUnit.SECONDS.sleep(5);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    Object o = new Object();
    System.out.println(ClassLayout.parseInstance(o).toPrintable());
}

运行发现，锁状态为101可偏向锁状态了，只是由于o对象未被用于synchronized加锁，所以线程id是空的。其余数据跟上述无锁状态一样

在这里插入图片描述

有线程使用锁

private static void biasedLock() {
    //先睡眠5秒，保证开启偏向锁
    try {
        TimeUnit.SECONDS.sleep(5);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    Object o = new Object();
    System.out.println(ClassLayout.parseInstance(o).toPrintable());
    System.out.println("=========================================");
    new Thread(() -> {
        synchronized (o) {
            System.out.println(ClassLayout.parseInstance(o).toPrintable());
        }
    }, "t1").start();
}

在这里插入图片描述

偏向锁的撤销

当有另外一个线程逐步来竞争锁的时候，就不能再使用偏向锁了，要升级为轻量级锁(CAS)，使用的是等到竞争出现才释放锁的机制，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销
竞争线程尝试CAS更新对象头失败，会等到全局安全点（该时间点上没有字节码正在执行）撤销偏向锁，同时检查持有偏向锁的线程是否还在执行：
- 第一个线程正在执行Synchronized方法（处于同步块），它还没有执行完，其他线程来抢夺，该偏向锁会被取消掉并出现锁升级（偏向锁变成轻量锁），此时轻量级锁由原来持有偏向锁的线程持有，继续执行同步代码块，而正在竞争的线程会自动进入自旋等待获得该轻量级锁
- 第一个线程执行完Synchronized（退出同步块）（B线程抢锁的时候，A线程刚好结束），则将对象头设置为无锁状态并撤销偏向锁，重新偏向。

题外话：Java15以后逐步废弃偏向锁，需要手动开启（JVM参数），因为维护成本高

在这里插入图片描述

在 Java 15 及之后的版本中逐步废弃偏向锁，主要有以下几个原因：

1. 应用场景有限：偏向锁主要适用于只有一个线程频繁访问同步块或方法的情况。然而，在现代多线程应用中，线程竞争通常更加复杂和多样化，这种单一线程频繁访问的情况相对较少。

例如，在一个高并发的 Web 应用中，多个线程可能同时访问和操作共享资源，而不是只有一个线程独占。

2. 性能开销：虽然偏向锁在特定情况下可以减少锁获取的开销，但在多线程竞争激烈时，它需要进行锁的升级和调整，这可能会带来额外的性能开销。

比如，当多个线程频繁竞争一个被偏向的锁时，系统需要进行一系列的操作来撤销偏向状态，转换锁的类型，这可能会导致性能下降。

3. 维护复杂性：偏向锁的实现和管理增加了 Java 虚拟机（JVM）内部的复杂性。

为了处理偏向锁的各种状态转换和维护相关数据结构，JVM 需要消耗更多的资源和代码复杂度。

综上所述，由于其有限的应用场景、可能带来的性能开销以及增加的维护复杂性，Java 在 15 及之后的版本中逐步废弃了偏向锁，以优化和简化多线程环境下的锁机制，提高整体性能和可维护性。

轻量锁

概念：存在多线程竞争，但是任意时候最多只有一个线程来竞争，即不存在锁竞争太激烈的情况，也就没有线程阻塞。

主要作用：有线程来参与锁的竞争，但是获取锁的冲突时间极短（本质是自旋锁CAS）

在这里插入图片描述

轻量锁获取过程

轻量级锁是为了在线程近乎交替执行同步块时提高性能。

主要目的：在没有多线程竞争的前提下，通过CAS减少重量级锁使用操作系统互斥量产生的性能消耗，说白了先自旋，不行才升级阻塞。

升级时机：当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁

假如线程A己经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁己经被线程A拿到，当前该锁己是偏向锁了。
而线程B在争抢时发现对象头Mark Word中的线程ID不是线程B自己的线程ID(而是线程A)，那线程B就会进行CAS操作希望能获得锁。比时线程B操作中有两种情况：
- 如果锁获取成功，直接替换Mark Word中的线程ID为B的ID(A->B)，重新偏向于其他线程（即将偏向锁交给B线程，相当于当前线程"被"释放了锁)，该锁会保持偏向锁状态，A线程Over，B线程上位；
- 如果锁获取失败，则偏向锁升级为轻量级锁（设置偏向锁标识为0并设置锁标志位为00），此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁

轻量级锁的加锁

JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，官方称为Displaced Mark Word。若一个线程获得锁时发现是轻量级锁，会把锁的MarkWord复制到自己的Displaced Mark Word里面。然后线程尝试用CAS将锁的MarkWord替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在与其它线程竞争锁，当前线程就尝试使用自旋来获取锁。

自旋CAS：不断尝试去获取锁，能不升级就不升级，尽量不要阻塞

轻量级锁的释放

在释放锁时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。

案例演示

如果设置关闭了偏向锁，程序默认就会使用轻量锁

在这里插入图片描述

轻量锁升级为重量锁

自旋次数超过上限，会升级为重量级锁

JDK6之前，默认最大次数=10，可以通过-XX:PreBlockSpin=10来修改（用默认就行）
JDK8之后是自适应自旋锁，意味着自旋的次数不是固定不变的，根据同一个锁上一次自旋的时间、拥有锁线程的状态来决定
- 线程如果自旋成功了，那下次自旋的最大次数会增加，因为JVM认为既然上次成功了，那么这一次也大概率会成功，不成功就多试几次
- 如果很少会自选成功，那么下次会减少自旋的次数甚至不自旋，避免CPU空转

轻量锁和偏向锁的区别

争夺轻量锁失败时，自旋尝试抢占锁
轻量级锁每次退出同步块都需要释放锁（成本比偏向锁高一点），而偏向锁是在竞争发生时才释放锁

重量锁

有大量线程参与锁的竞争，冲突性很高，就会从轻量级锁升级为重量级锁
在这里插入图片描述

Java中synchronized的重量级锁，是基于进入和退出Monitor对象实现的。在编译时会将同步块的开始位置插入monitor enter指令，在结束位置插入monitor exit指令。
当线程执行到monitor enter指令时，会尝试获取对象所对应的Monitor所有权，如果获取到了，即获取到了锁，会在Monitor的owner中存放当前线程的id，这样它将处于锁定状态，除非退出同步块，否则其他线程无法获取到这个Monitor。

在这里插入图片描述

小结

锁升级的过程

在这里插入图片描述

锁升级后，hashcode去哪儿了?

在这里插入图片描述

问：锁升级为轻量级或重量级锁后，Mark Word中保存的分别是线程栈帧里的锁记录指针和重量级锁指针，己经没有位置再保存哈希码， GC年龄了，那么这些信息被移动到哪里去了呢？

在Java语言里面一个对象如果计算过哈希码，就应该一直保持该值不变（强烈推荐但不强制一定保持不变，因为用户可以重载hashCode()方法按自己的意愿返回哈希码)，否则很多依赖对象哈希码的API都可能存在出错风险。而作为绝大多数对象哈希码来源的Object::hashCode()方法，返回的是对象的一致性哈希码(Identity Hash Code)，这个值是能强制保证不变的，它通过在对象头中存储计算结果来保证第一次计算之后，再次调用该方法取到的哈希码值水远不会再发生改变。因此，当一个对象已经计算过一致性哈希码后，它就再也无法进入偏向锁状态了；而当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁。在重量级锁的实现中，对象头指向了重量级锁的位置，代表重量级锁的ObjectMonitor类里有字段可以记录非加锁状态（标志位为“01”）下的Mark Word，其中自然可以存储原来的哈希码。

在无锁状态下，Mark Word中可以存储对象的identity hash code值。当对象的hashCode()方法第一次被调用时，JVM会生成对应的identity hash code值并将该值存储到Mark Word中。
对于偏向锁，在线程获取偏向锁时，会用Thread ID和epoch值覆盖identity hash code所在的位置。如果一个对象的hashCode()方法已经被调用过一次之后，这个对象不能被设置偏向锁。因为如果可以的话，那Mark Word中的identity hash code必然会被偏向线程id给覆盖，这就会造成同一个对象前后两次调用hashCode()方法得到的结果不一致。
升级为轻量级锁时，JVM会在当前线程的栈帧中创建一个锁记录(Lock Record)空间，用于存储锁对象的Mark Word拷贝，该拷贝中可以包含identity hash code，所以轻量级锁可以和identity hash code共存，哈希码和GC年龄自然保存在此，释放锁后会将这些信息写回到对象头。
升级为重量级锁后，Mark Word保存的重量级锁指针，代表重量级锁的ObjectMonitor类里有字段记录非加锁状态下的Mark Word，锁释放后也会将信息写回到对象头。

测试

【当一个对象已经计算过identity hash code它就无法进入偏向锁状态跳过偏向锁，直接升级为轻量级锁】

//先睡眠5秒，保证开启偏向锁
try { TimeUnit.SECONDS.sleep(5); } catch (InterruptedException e) { e.printStackTrace(); }

Object o = new Object();
System.out.println("本应是偏向锁");
System.out.println(ClassLayout.parseInstance(o).toPrintable());

o.hashCode();//没有重写，一致性哈希，重写后无效,当一个对象已经计算过identity hash code，它就无法进入偏向锁状态；

synchronized (o){
    System.out.println("本应是偏向锁，但是由于计算过一致性哈希，会直接升级为轻量级锁");
    System.out.println(ClassLayout.parseInstance(o).toPrintable());
}

在这里插入图片描述

【偏向锁过程中遇到一致性哈希计算请求立马撤销偏向模式，膨胀为重量级锁】

//先睡眠5秒，保证开启偏向锁
try {
    TimeUnit.SECONDS.sleep(5);
} catch (InterruptedException e) {
    e.printStackTrace();
}
Object o = new Object();

synchronized (o) {
    o.hashCode();//没有重写，一致性哈希，重写后无效
    System.out.println("偏向锁过程中遇到一致性哈希计算请求，立马撤销偏向模式，膨胀为重量级锁");
    System.out.println(ClassLayout.parseInstance(o).toPrintable());
}

在这里插入图片描述

各种锁优缺点

在这里插入图片描述

偏向锁：适用于单线程适用的情况，在不存在锁竞争的时候进入同步方法/代码块则使用偏向锁。
轻量级锁：适用于竞争较不激烈的情况（这和乐观锁的使用范围类似），存在竞争时升级为轻量级锁，轻量级锁采用的是自旋锁，如果同步方法/代码块执行时间很短的话，采用轻量级锁虽然会占用cpu资源但是相对比使用重量级锁还是更高效。
重量级锁：适用于竞争激烈的情况，如果同步方法/代码块执行时间很长，那么使用轻量级锁自旋带来的性能消耗就比使用重量级锁更严重，这时候就需要升级为重量级锁。

synchronized锁升级和实现原理

synchronized锁升级过程总结：一句话，就是先自旋，不行再阻塞。实际上是把之前的悲观锁（重量级锁）变成在一定条件下使用偏向锁以及使用轻量级（自旋锁CAS）的形式
synchronized在修饰方法和代码块在字节码上实现方式有很大差异，但是内部实现还是基于对象头的MarkWord来实现的
JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁->偏向锁->轻量级锁->重量级锁的升级过程，而不是无论什么情况都使用重量级锁

口诀

没有锁：自由自在
偏向锁：唯我独尊
轻量锁：楚汉争霸
重量锁：群雄逐鹿

JIT编译器对锁的优化

JIT

Just In Time Compiler 即时编译器

锁消除

public class LockClearUPDemo {
    static Object objectLock = new Object();

    public void m1() {
        /*synchronized (objectLock){
            System.out.println("-----hello LockClearUPDemo");
        }*/

        // 锁消除问题
        // 每个线程new一个Object，这个锁没有意义，JIT编译器会无视它
        // 这个锁对象并没有被共用扩散到其它线程使用，极端的说就是根本没有加这个锁对象的底层机器码，消除了锁的使用
        Object o = new Object();
        synchronized (o) {
            System.out.println("-----hello LockClearUPDemo" + "\t" + o.hashCode() + "\t" + objectLock.hashCode());
        }
    }

    public static void main(String[] args) {
        LockClearUPDemo lockClearUPDemo = new LockClearUPDemo();

        for (int i = 1; i <= 10; i++) {
            new Thread(() -> {
                lockClearUPDemo.m1();
            }, String.valueOf(i)).start();
        }
    }
}

锁粗化

/**
 * 锁粗化
 * 假如方法中首尾相接，前后相邻的都是同一个锁对象，那JIT编译器就会把这几个synchronized块合并成一个大块，
 * 加粗加大范围，一次申请锁使用即可，避免次次的申请和释放锁，提升了性能
 */
public class LockBigDemo {
    static Object objectLock = new Object();

    public static void main(String[] args) {
        new Thread(() -> {
            synchronized (objectLock) {
                System.out.println("111111");
            }
            synchronized (objectLock) {
                System.out.println("222222");
            }
            synchronized (objectLock) {
                System.out.println("333333");
            }
            synchronized (objectLock) {
                System.out.println("444444");
            }
            synchronized (objectLock) {
                System.out.println("111111");
                System.out.println("222222");
                System.out.println("333333");
                System.out.println("444444");
            }
        }, "t1").start();
    }
}