【JUC】Synchronized与锁升级

news/2024/12/2 10:27:37/

【JUC】Synchronized与锁升级

文章目录

  • 【JUC】Synchronized与锁升级
    • 1. 概述
      • 1.1 无锁
      • 1.2 偏向锁
      • 1.3 轻量级锁
      • 1.4 重量级锁
    • 2. 问题
      • 2.1 哈希码去哪了？
      • 2.2 锁消除
      • 2.3 锁粗化
    • 3. 锁的优缺点的对比

1. 概述

用锁能够实现数据的安全性，但是会带来性能下降。无锁能够基于线程并行提升程序性能，但是会带来安全性下降。如何达到两者的平衡呢？

synchronized 用的锁是存在java对象头里的 Mark Word 中。锁升级功能主要依赖 Mark Word 中锁标志位和释放偏向锁位

image-20230522224429954

偏向锁：Mark Word 存储的是偏向的线程ID。

轻量锁：Mark Word 存储的是指向线程栈中 Lock Record 的指针。

重量锁：Mark Word 存储的是指向堆中的 monitor 对象的指针。

1.1 无锁

image-20230522234428970

public class MyObject{public static void main(String[] args){Object o = new Object();System.out.println("10进制hash码："+o.hashCode());System.out.println("16进制hash码："+Integer.toHexString(o.hashCode()));System.out.println("2进制hash码："+Integer.toBinaryString(o.hashCode()));System.out.println( ClassLayout.parseInstance(o).toPrintable());}
}

运行结果如下所示：

image-20230522230841743

注：Mark Word 怎么看呢？

总体上是由右下往左上看，每8位从左往右看。所以前25位是没用的，都是0。根据规则，第25位是第二行第一个数字也是0。哈希码是第26位(第2行第2位)至第57位(第1行第9位)。偏向锁位第62位(第一行第6位)，锁标志位第63位至第64位(第一行第7位至第8位)。

1.2 偏向锁

偏向锁：当一个线程第一次获得锁时，JVM会将锁对象头中的标志位设置为“偏向模式”，同时将其线程ID记录在对象头中。此后，如果这个线程再次请求锁，JVM会直接将锁分配给该线程，跳过竞争锁的过程，从而避免了无谓的锁竞争和线程上下文切换，提高了程序的执行效率。

image-20230522234453790

使用条件:

  1. 大部分情况下，锁只被一个线程获取。
  2. 对象的生命周期内，锁定操作仅在少数时间发生。

偏向锁的出现是为了解决只有在一个线程执行同步时提高性能。

在实际应用运行过程中发现，“锁总是同一个线程持有，很少发生竞争”，也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。

​ 那么只需要在锁第一次被拥有的时候，记录下偏向线程ID。这样偏向线程就一直持有锁（后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接回去检查锁的 Mark Word 里面是不是放的自己的线程ID）。

​ 如果相等，表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程ID与当前线程ID是否一致，如果一致直接进入同步。无需每次加锁解锁都去CAS更新对象头。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外的开销，性能极高。

​ 如果不等，表示发生了竞争，锁已经不是总是偏向于同一个线程了，这个时候会尝试使用CAS来替换 Mark Word 里面的线程ID为新线程的ID。

​ 竞争成功，表示之前的线程不存在了，Mark Word 里面的线程ID为新线程的ID，锁不会升级，仍然为偏向锁。

​ 竞争失败，这时候可能需要升级变为轻量级锁，才能保证线程间公平竞争锁。

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

技术实现：

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

偏向锁的操作不用直接捅到操作系统，不涉及用户态到内核态转换，不必要直接升级为最高级，我们以一个 account 对象的“对象头为例”，

image-20230523210327955

假如有一个线程执行到 synchronized 代码块的时候，JVM使用 CAS 操作把线程指针ID记录到 Mark Word 当中，并修改偏向标识，标示当前线程获得该锁。锁对象变成偏向锁（通过 CAS 修改对象头里的锁标志位），字面意思是“偏向第一个获得它的线程”的锁。执行完同步代码块后，线程并不会主动释放偏向锁。

image-20230523210931255

这时线程获得了锁，可以执行同步代码块。当该线程第二次到达同步代码块时会判断此时持有锁的线程是否还是自己（持有锁的线程ID也在对象头里），jvm通过account对象的对象头判断：当前线程ID还在，说明还持有这个对象的锁，就可以继续进入临界区工作。**由于之前没有释放锁，这里也就不需要重新加锁。**如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。

结论：jvm不用和操作系统协商 Mutex (争取内核)，它只需要记录下线程ID就标示自己获得了当前锁，不用操作系统介入。

开启偏向锁并关闭延时：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0

关闭偏向锁(进入轻量级锁)：-XX:-UseBiasedLocking

参数说明：

偏向锁在 JDK1.6以后默认开启，开启后程序启动几秒后才会被激活，可以使用jvm参数来关闭延迟 -XX:BiasedLockingStartupDelay=0 。

如果确定锁通常处于竞争状态则可以通过jvm参数 -XX:-UseBiasedLocking 关闭偏向锁，那么默认会进入轻量级锁。

演示偏向锁：

image-20230523221249260

偏向锁的撤销：

偏向锁使用一种等到竞争出现才释放锁的机制，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。撤销需要等待全局安全点（该时间点上没有字节码正在执行）同时检查持有偏向锁的线程是否还在执行：

①：第一个线程正在执行 synchronized 方法（处于同步块），它还没有执行完，其他线程来抢夺，该偏向锁会被取消掉并出现锁升级。此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码块，而正在竞争的线程会进入自旋等待获得该轻量级锁。

②：第一个线程执行完成 synchronized 方法（退出同步块），则将对象头设置成无锁状态并撤销偏向锁，重新偏向。

锁升级示意图：

img

1.3 轻量级锁

轻量级锁：多线程竞争，但是任意时刻最多只有一个线程竞争，即不存在锁竞争太过激烈的情况，也就没有线程阻塞。

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

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

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

假如线程A已经拿到了锁，这时线程B又来抢该对象的锁，由于该对象的锁已经被线程A拿到，当前该锁已经是偏向锁了。

而线程B在争抢时发现对象头 Mark Word 中的线程ID不是线程B自己的线程ID(而是线程A的)，那么线程B就会进行 CAS 操作希望能获得锁。

此时线程B操作中有两种情况：

①：如果锁获取成功，直接替换 Mark Word 中的线程ID位线程B自己的ID，重新偏向于其他线程（即将偏向锁交给了其他线程，相当于当前线程“被”释放了锁），该锁会保持偏向锁状态，A线程over，B线程上位。

image-20230524162336866

②：如果锁获取失败，则偏向锁升级为轻量级锁，此时轻量级锁由原持有偏向锁的线程持有，继续执行同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁。

image-20230524160617074

轻量级锁的加锁：

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

轻量级锁的释放：

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

自旋达到多少次或什么程度才会升级为重量锁呢？

Java6之前：

  • 默认启用，默认情况10次。可以根据 -XX:PreBlockSpin=10 来修改
  • 自旋线程数超过cpu核数的一半

Java6之后：

  • 自适应：自适应意味着自旋的次数不是固定不变的。而是根据同一个锁上一次自旋的时间及拥有锁线程的状态来决定的。

自适应自旋锁的大致原理：线程如果自旋成功了，那下次自旋的最大次数会增加，因为JVM认为既然上次成功了，那么这一次大概率也会成功。反之，如果很少会自旋成功，那么下次会减少自旋的次数甚至不自旋，避免cpu空转。

轻量级锁和偏向锁的区别和不同：

  • 争夺轻量级锁失败时，自旋尝试抢占锁。
  • 轻量级锁每次退出同步代码块都需要释放锁，而偏向锁是在竞争发生时才释放锁。

1.4 重量级锁

重量级锁：有大量的线程参与锁的竞争，冲突性很高。

image-20230524191114214

2. 问题

2.1 哈希码去哪了？

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

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

测试：

当一个对象已经计算过哈希码，它就无法进入偏向锁状态，跳过偏向锁，直接升级轻量级锁。

代码如下：

public class SynchronizedUpDemo {public static void main(String[] args) {//先睡眠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());}}
}

结果如下：

image-20230524201444191

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

代码如下:

public class SynchronizedUpDemo {public static void main(String[] args) {//先睡眠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());}}
}

结果如下：

image-20230524201741713

2.2 锁消除

从 JIT 编译器角度看相当于无视了锁，synchronized (o) 不存在了，这个锁对象并没有被共用扩散到其他线程使用，极端的说就是根本没有加这个锁对象的底层机器码，消除了锁的作用。

public class LockClearUPDemo {static Object objectLock = new Object();public void m1() {/*synchronized (objectLock){System.out.println("-----hello LockClearUPDemo");}*///锁消除问题，JIT编译器会无视它 ，synchronized(o),每次new出来的，不存在了，非正常的。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();}}
}

运行结果：

image-20230524203304972

2.3 锁粗化

假如方法中首尾相接，前后相邻的都是同一个锁对象，那么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();}
}

3. 锁的优缺点的对比

image-20230524202317698

synchronized锁升级过程总结：一句话，就是先自旋，不行再阻塞。

实际上是把之前的悲观锁(重量级锁)变成在一定条件下使用偏向锁以及使用轻量级(自旋锁CAS)的形式。

偏向锁:适用于单线程适用的情况，在不存在锁竞争的时候进入同步方法/代码块则使用偏向锁。

轻量级锁：适用于竞争较不激烈的情况(这和乐观锁的使用范围类似)， 存在竞争时升级为轻量级锁，轻量级锁采用的是自旋锁，如果同步方法/代码块执行时间很短的话，采用轻量级锁虽然会占用cpu资源但是相对比使用重量级锁还是更高效。

重量级锁：适用于竞争激烈的情况，如果同步方法/代码块执行时间很长，那么使用轻量级锁自旋带来的性能消耗就比使用重量级锁更严重，这时候就需要升级为重量级锁。

总结：

没有锁：自由自在

偏向锁：唯我独尊

轻量锁：楚汉争霸

重量锁：群雄逐鹿


http://www.ppmy.cn/news/79516.html

相关文章

【Linux】线程分离 | 线程库 | C++调用线程 | 线程局部存储

【Linux】线程分离 | 线程库 | C++调用线程 | 线程局部存储

文章目录 1. 线程分离1. 为什么要线程分离&#xff1f;2. 具体使用3. 为什么有时候分离在调用join 会正常运行&#xff1f; 2. 如何理解线程库&#xff1f;如何理解 先描述 在组织&#xff1f; 3. C中使用多线程4. 线程局部存储局部变量全局变量 1. 线程分离 1. 为什么要线程分…
阅读更多...
2023 LitCTF --- Crypto wp

2023 LitCTF --- Crypto wp

文章目录 前言easy_mathEulerbabyLCGbaby_xor 前言 由于探姬小姐姐&#xff08;bushi)跟我讲LitCTF是一个新生赛捏&#xff0c;所以我出的几个题题目都是比较简单&#xff0c;偏向于新手向。这里面可能有一点难度的题目就是baby_xor了&#xff0c;简单考一下copper定理&#x…
阅读更多...
高性能容器之Apptainer

高性能容器之Apptainer

1.Apptainer简介 Apptainer是一个开源容器平台&#xff0c;旨在简单&#xff0c;快速&#xff0c; 和安全。有许多容器平台可用&#xff0c;但 Apptainer 的设计 便于在共享系统和高性能计算 &#xff08;HPC&#xff09; 中使用 环境。它的特点是&#xff1a; 不可变的单文件…
阅读更多...
Flink入门

Flink入门

目录 一、Flink简介 二、为什么选择Flink 三、与传统数据处理架构相比 四、Flinik批处理数据基础代码 五、Flink流处理基础代码 一、Flink简介 Apache Flink 是一个框架和分布式处理引擎&#xff0c;用于对无界和有界数 据流进行状态计算。 二、为什么选择Flink 流数据更…
阅读更多...
00后是真卷不过，工作没两年，跳槽到我们公司起薪20K都快接近我了

00后是真卷不过，工作没两年，跳槽到我们公司起薪20K都快接近我了

在程序员职场上&#xff0c;什么样的人最让人反感呢? 是技术不好的人吗?并不是。技术不好的同事&#xff0c;我们可以帮他。 是技术太强的人吗?也不是。技术很强的同事&#xff0c;可遇不可求&#xff0c;向他学习还来不及呢。 真正让人反感的&#xff0c;是技术平平&…
阅读更多...
Vue之数据代理（getter、setter）

Vue之数据代理（getter、setter）

文章目录 前言一、数据代理1.Object.defineProperty()2.数据代理讲解 总结 前言 Object.defineProperty 数据代理 一、数据代理 1.Object.defineProperty() &#xff08;1&#xff09;实例对象可以通过Object.defineProperty()方法来添加属性&#xff0c;但是添加的属性默认…
阅读更多...
win7下java环境搭建以及jdk环境变量配置

win7下java环境搭建以及jdk环境变量配置

很多人在搭建页游、手游时候经常遇到JAVA闪退&#xff0c;基本都是环境变量或者路径错误导致的。本章节主要讲解在win7系统环境下&#xff0c;java环境变量配置方法&#xff0c;java环境配置正确&#xff0c;才可以对apk程序进行反编译运行页游手游。其他操作系统环境变量大同小…
阅读更多...
react native 集成腾讯语音合成TTS(iOS)

react native 集成腾讯语音合成TTS(iOS)

一、前言 从我去年集成好安卓的代码，已经过去了大半年了，sdk的版本也从1.5升级到了2.0，近期终于完成了ios的集成，希望可以帮助到大家。本人）Objective C写的不好，代码可能不是那么大的完备，仅作参考学习。 二、下载sdk 需要登陆腾讯云，找到语音技术，下载sdk 文档链…
阅读更多...
最新文章

Copyright @ 2022~2023