- 综合排序
- 最热优先
- 最新优先
Java EE(9)——线程安全——锁升级&JUC&集合类
1.synchronized锁升级 上篇博文介绍了各种锁策略，那么在此基础上我再对常用的synchronized的优化策略进行讲解 synchronized (锁对象) { //其他代码 } 当我们使用 synchronized对某一代码块加锁的时候，synchronized并不会在第一时间加锁，而是经历了（偏向锁——>轻量级锁——>重量级锁）这样的锁升级过程。 偏向锁 当一个线程第一次访问同步块时，JVM会尝试将该线程的ID记录在锁对象的对象头中，并标记为偏向锁。 之后，当该线程再次进入同步块时，直接进入同步块 偏向锁——>轻量级锁 如果有其他线程尝试获取该锁，偏向锁会被撤销，升级为轻量级锁 轻量级锁——>重量级锁 当thread1等待了很久(自旋了很多次 JVM看到这里的竞争太大，会考虑把lock升级为重量级锁 2.JUC(java.util.concurrent) 的常见类 2.1ReentrantLock 可重入互斥锁，和synchronized
13210编辑于 2026-01-13- 来自专栏JAVA
synchronized锁升级
synchronized锁升级 博主 默语带您 Go to New World. 锁的优化：从无锁到重量级锁 Java 在 JDK 6 之后通过 偏向锁、轻量级锁 和 重量级锁 提高了锁的性能。这些优化基于对象头中的 MarkWord 字段实现。 标志位： 偏向锁标志：0 锁标志：01 偏向锁 特点：偏向锁旨在优化单线程情况下的锁获取开销，避免CAS操作。 获取过程： 检查锁标志为 01 且偏向锁标志为 0。 偏向锁的升级 如果锁竞争发生，偏向锁可能升级为轻量级锁。 轻量级锁 特点：通过自旋等待来实现，适合短时间内无大量竞争的场景。 撤销：轻量级锁会在使用后主动撤销，将 MarkWord 恢复原值。 升级：若自旋超出限定次数或有大量线程竞争，升级为重量级锁。
31110编辑于 2024-11-25 - 来自专栏java
synchronized和锁升级，以及偏向锁和轻量级锁的升级
4: aload_0 5: dup 6: getfield #2 // Field i:I 9: 锁的优化 锁的 4 中状态：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态（级别从低到高），整个锁的状态从低到高变化的过程被称为所升级。 为什么要引入偏向锁？ 轻量级锁什么时候升级为重量级锁？ 重量级锁把除了拥有锁的线程都阻塞，防止 CPU 空转。」 ❝ 注意：为了避免无用的自旋，轻量级锁一旦膨胀为重量级锁就不会再降级为轻量级锁了；偏向锁升级为轻量级锁也不能再降级为偏向锁。 一句话就是锁可以升级不可以降级，但是偏向锁状态可以被重置为无锁状态。
41110编辑于 2025-06-28 - 来自专栏JAVA乐园
synchronized的锁升级、锁膨胀
0x01：偏向锁 偏向第一个拿到锁的线程。 即第一个拿到锁的线程，锁会在对象头 Mark Word 中通过 CAS 记录该线程 ID，该线程以后每次拿锁时都不需要进行 CAS（指轻量级锁）。 如果该线程正在执行同步代码块时有其他线程在竞争（指其他线程尝试 CAS 让 Mark Word 设置自己的线程 ID），会被升级为轻量级锁。 如果成功，表示线程拿到了锁。如果失败，则进行自旋（自旋锁），自旋超过一定次数时升级为重量级锁，这时该线程会被内核挂起。 升级为重量级锁时会在堆中创建 monitor 对象，并将 Mark Word 指向该 monitor 对象。 图片来自：死磕Synchronized底层实现--重量级锁 锁升级的流程图 ? 图片来自：Java Synchronised机制 0x05：锁降级 Hotspot 在 1.8 开始有了锁降级。
1.3K10发布于 2020-06-15 - 来自专栏Java并发编程
我将独自升级！-- 锁升级
我将独自升级！-- 锁升级 大家好，我是小高先生。在经过对锁的基础知识和对象头概念的学习之后，相信各位已经对锁机制有了初步的了解。在之前的文章中，我有提到过关于锁升级的概念。 这样的权衡和折中，也是锁机制设计的智慧所在。因此，为了找到一个平衡点，Java中的锁机制引入了一个过程，即“锁升级”。 如果争夺成功，Mark Word会记录新的线程ID，但偏向锁不会升级。如果争夺失败，那竞争会依旧存在，此时偏向锁升级为轻量级锁，以便更公平的处理多线程之间的竞争关系。 自旋一定次数后线程还没获取到锁，轻量级锁就会升级为重量级锁,，因为自旋会消耗CPU。在Java 6之前，默认情况下自旋次数超过10次升级，或者自选线程数超过CPU核数一般，了解即可。 如果对象处于偏向状态，此时又调用了hashCode()，偏向锁会被撤销，升级为重量级锁。
61700编辑于 2024-03-01 - 来自专栏业余草
详解synchronized和锁升级，以及偏向锁和轻量级锁的升级
4: aload_0 5: dup 6: getfield #2 // Field i:I 9: 锁的优化 锁的 4 中状态：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态（级别从低到高），整个锁的状态从低到高变化的过程被称为所升级。 为什么要引入偏向锁？ 轻量级锁什么时候升级为重量级锁？ 重量级锁把除了拥有锁的线程都阻塞，防止 CPU 空转。」 ❝ 注意：为了避免无用的自旋，轻量级锁一旦膨胀为重量级锁就不会再降级为轻量级锁了；偏向锁升级为轻量级锁也不能再降级为偏向锁。 一句话就是锁可以升级不可以降级，但是偏向锁状态可以被重置为无锁状态。
2K42编辑于 2021-12-06 - 来自专栏SpringBoot教程
Synchronized与锁升级
锁种类及升级步骤 1、多线程访问情况，3种 1）只有一个线程来访问，有且唯一Only One 2）有2个线程A、B来交替访问 3）竞争激烈，多个线程来访问 2、升级流程 synchronized用的锁是存在 为新线程的ID，锁不会升级，认为偏向锁 竞争失败，这时候可能需要升级为轻量级锁，才能保证线程间公平竞争锁 注意：偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的 升级时机： 当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁 假如线程A已经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁已经被线程A拿到，当前该锁已是偏向锁了。 锁升级过程总结：一句话，就是先自旋，不行再阻塞。 重量级锁：适用于竞争激烈的情况，如果同步方法/代码块执行时间很长，那么使用轻量级锁自旋带来的性能消耗就比使用重量级锁更严重，这时候就需要升级为重量级锁。
47121编辑于 2023-02-16 - 来自专栏CBeann的博客
synchronized锁升级原理
64操作系统下，Mark Word的长度是64，在加Klass Word(32位)，一共是96位，其实对象头长什么样其实不是本文的重点，本文的重点是验证锁升级的过程，所以我们只需要关注对象头中Mark 锁升级的过程 锁状态 25bit 4bit 1bit 2bit 23bit 2bit 是否偏向锁 锁标志位 1 无锁 对象的HashCode 分代年龄 0 01 2 无锁 对象的HashCode ---->偏向锁状态 单线程访问锁的时候，锁由无锁状态变为偏向锁状态。 偏向锁状态---->轻量级锁状态 多线程使用锁（不竞争，错开时间访问），锁由偏向锁状态变为轻量级锁状态 // -XX:BiasedLockingStartupDelay=0 public class SynchronizedDemo 总结 单线程使用锁的时候为偏向锁。 多线程无竞争（错峰使用锁）的时候为轻量级锁。 有竞争的时候为重量级锁。
35310编辑于 2023-12-25 - 来自专栏刷题笔记
锁升级：无锁、偏向锁、轻量级锁、重量级锁
锁升级 JDK 1.6之前，synchronized 还是一个重量级锁，是一个效率比较低下的锁。 并且四种状态会随着竞争的情况逐渐升级，而且是不可逆的过程，即不可降级，这四种锁的级别由低到高依次是：无锁、偏向锁，轻量级锁，重量级锁。如下图所示： ? 轻量级锁 轻量级锁是指当锁是偏向锁的时候，却被另外的线程所访问，此时偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，线程不会阻塞，从而提高性能。 轻量级锁的获取主要由两种情况： 当关闭偏向锁功能时； 由于多个线程竞争偏向锁导致偏向锁升级为轻量级锁。 一旦有第二个线程加入锁竞争，偏向锁就升级为轻量级锁（自旋锁）。 如果锁竞争情况严重，某个达到最大自旋次数的线程，会将轻量级锁升级为重量级锁（依然是CAS修改锁标志位，但不修改持有锁的线程ID）。
3.5K20发布于 2021-04-14 - 来自专栏侯哥的Python分享
MySQL高级9-锁
二、分类 MySQL中的锁、按照锁的粒度分，分为以下三类 全局锁：锁定数据量的所有表 表级锁：每次操作锁住整张表 行级锁：每次操作锁住对应的行数据 三、全局锁 3.1 简介 全局锁就是对整个数据库实例枷锁 说明5：当线程B 再次添加表锁的时候，就不用逐行排查是否有行锁了，而是直接检查整表是否有意向锁，如果意向锁和表锁兼容则直接加表锁 说明6：如果表锁和意向锁不兼容，则仍然会等到意向锁释放了，表锁才能添加成功 说明5：排他意向锁与共享read锁和排他write锁都互斥 说明6：意向锁的作用主要是解决行锁和表锁之间的矛盾。 不通过索引检索数据，那么InnoDB将对表中的所有记录加锁，此时就会升级为表锁 8.3 行锁案例 说明1：客户端1开始事务，并执行查询语句，客户端2锁的情况，显示为空表 说明2： 说明9：InnoDB的行锁是针对于索引加的锁，不通过索引检索数据，那么InnoDB将对表中的所有记录加锁，此时就会升级为表锁 说明10：根据业务需要，尽量使用索引当所查询条件，既快又减少阻塞
43530编辑于 2023-09-06 - 来自专栏用户8532457的专栏
CAS、ABA问题、锁升级
锁升级 首先执行下面这一段代码： Object o = new Object(); System.out.println(ClassLayout.parseInstance(o).toPrintable ： 1.刚刚new出对象开始时未上锁 2.第一次对其加锁被称之为：偏向锁 3.接下来升级为轻量级锁：无锁或者自旋锁 4.最终升级为：重量级锁 理解自旋锁和无所：自旋锁：假如有一哥们在蹲坑，你在旁边转圈等待 你可以叫他自旋锁，也相当于不是锁，所以叫做：无锁 详细讲解锁升级过程： 无状态锁：new Object的时候。 ：只要被访问的资源处于竞争状态时，自动升级为自旋锁，多线程同时并发访问同一个为资源，此时每条线程在自己的线程栈当中生成一个Lock Record对象，并且开始以CAS的自旋方式去抢占被访问的资源，该资源会记录轻量级锁的指针 ，也就是说会不断的比较被抢占资源的值是否与自己的指针是否相等，如果相等，那么就修改该指针 重量级锁：当自旋锁长期处于自旋状态，太过于消耗CPU资源，于是升级为重量级锁，重量级锁是必须要由操作系统匹配的（
63330发布于 2021-05-13 synchronized 锁升级全流程
三、锁升级全流程核心原理 synchronized的锁升级是JVM为了减少同步开销而做的自适应优化，核心逻辑是：根据竞争激烈程度，从低开销锁逐步升级到高开销锁，锁的膨胀过程在持有期间是单向的，不可降级， 锁升级全流程总览 3.1 第一阶段：无锁状态 无锁状态分为两种子状态，是锁升级的起点： 无锁可偏向状态：开启偏向锁的前提下，对象刚创建，未调用过System.identityHashCode()，Mark 因此重量级锁适用于锁持有时间长、竞争激烈的场景，此时切换开销远小于CPU空转的开销。 四、锁升级全流程实战代码验证 以下所有代码均基于JDK17编写，用于验证上述锁升级的核心原理。 准确结论是：锁的膨胀过程在持有期间是单向的，只能从低级别升级到高级别，不可降级；但当锁完全释放后，对象的Mark Word会被重置为无锁状态，下一次竞争会重新开始锁升级流程。 轻量级锁：出现多线程交替竞争锁时，偏向锁被撤销，升级为轻量级锁。
15710编辑于 2026-04-14- 来自专栏Java患者
多线程--锁的升级
锁的存储 在多线程并发编程中,synchronized一般我们认为是重量级锁,但是随着JDK1.6的优化之后,在一些情况下它就不显得那么重量级了,因为在JDK1.6中为了减少获得锁和释放锁带来的性能消耗而引入了偏向锁跟轻量级锁 如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。 这里其实就是一种锁的升级，毕竟synchronized锁了代码是因为防止多个线程并发的时候对数据造成不安全，但是如果只有线程访问，那synchronized就太消耗性能了，所以做了偏向锁进行升级。。 轻量级锁 当偏向锁已经不足够使用的时候，会再次升级为轻量级锁，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁。 轻量级锁再加锁过程中，会使用到了自旋锁，而自旋锁就是指当有另外一个线程来竞争锁时，这个线程会在原地循环等待，而不是阻塞该线程，直到前面的线程释放锁了之后，这个线程就可以马上获得锁。
56930发布于 2020-07-14 - 来自专栏老付的网络博客
synchronized 锁的升级过程
主线程进入，锁升级为 00（轻量级锁） OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 线程 1 和线程 2 同时进入 ，存在竞争 ,升级位重量级锁 10 OFFSET SIZE TYPE DESCRIPTION VALUE 运行 hashcode 后，锁状态升级位无锁不可偏向 ，原本存放线程 ID 的位置被 hashcode 覆盖 OFFSET SIZE TYPE DESCRIPTION 线程 1 进入，无锁竞争，锁升级为轻量锁 000 OFFSET SIZE TYPE DESCRIPTION VALUE 0 线程 2 进入，存在锁竞争，锁升级为轻量锁 010 OFFSET SIZE TYPE DESCRIPTION VALUE 0
78530发布于 2021-03-07 - 来自专栏用户4480853的专栏
synchronized锁升级 发布于
1获取，升级为偏向锁。 然后当线程2试图获取锁时，偏向锁被撤销，变回无锁状态。再次由线程1获取时，锁被升级为轻量级锁。最后，当线程2再次试图获取锁时，锁被升级为重量级锁。 锁的升级一般发生在下述条件（在锁升级前会先进行锁的膨胀）： 无锁到偏向锁： 如果一个线程第一次访问一个synchronized块，JVM将会在对象头上记录这个线程ID，然后线程将持有偏向锁。 重量级锁 重新回到对象头中的源码，其实在轻量级锁中也提及了重量级锁在什么时候会进行升级（如果轻量级锁的CAS操作失败，则由JVM选择是否升级为重量级锁）开发者需要重点关注的是inflate(current [9] Lindholm, T., Yellin, F., Bracha, G., & Buckley, A. (2015).
66730编辑于 2023-10-21 - 来自专栏『学习与分享之旅』
Synchronized 原理与锁升级
，锁可以从 偏向锁 升级到 轻量级锁，再升级到 重量级锁但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级Java 对象结构对象头Mark WordMark Word（标记字）主要用来表示对象的线程锁状态 ，则表示有竞争当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁 升级为 轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码（5）执行同步代码偏向锁的释放偏向锁只有遇到其他线程尝试竞争偏向锁时 的优化但是这两种锁也不是完全没缺点的，比如竞争比较激烈的时候，不但无法提升效率，反而会降低效率，因为多了一个锁升级的过程这个时候就需要通过 -XX:-UseBiasedLocking 来禁用偏向锁几种锁的对比图片锁升级代码演示创建一个 obj) { System.out.println(ClassLayout.parseInstance(obj).toPrintable()); } }}图片升级轻量极锁图片 System.out.println(ClassLayout.parseInstance(obj).toPrintable()); } }).start(); }}图片升级重量级锁
47530编辑于 2023-09-30 - 来自专栏小工匠聊架构
MySQL - 无索引行锁升级为表锁
---- ---- 无索引行锁升级为表锁演示 表结构 mysql> desc country; +-------------+--------------+------+-----+---------+ anotherline’ ; ---- 一直被阻塞 ，直到超时 1205 - Lock wait timeout exceeded; try restarting transaction 我们知道锁主要是加在索引上 ，如果对非索引字段更新，行锁可能会变表锁 , 从上面的测试中也可以验证这个观点，第二个 ---- 结论 InnoDB的行锁是针对索引加的锁，不是针对记录加的锁 ,并且该索引不能失效，否则会从行锁升级为表锁
2.8K20发布于 2021-08-17 - 来自专栏运维记录
rocky 9 升级内核版本
-6.1.80-1.el9.elrepo.x86_64.rpm -rw-r--r-- 1 root root 48351469 Oct 30 13:38 kernel-lt-core-6.1.80-1. el9.elrepo.x86_64.rpm -rw-r--r-- 1 root root 47088209 Oct 30 13:38 kernel-lt-modules-6.1.80-1.el9.elrepo.x86 -1.el9.elrepo.x86_64.rpm kernel-lt-6.1.80-1.el9.elrepo.x86_64.rpm 设置系统默认内核版本 查看系统中所有的内核 # grubby --info Linux (6.1.80-1.el9.elrepo.x86_64) 9.2 (Blue Onyx)" id="a674b449cbd146d79b33888bb5ad39c4-6.1.80-1.el9 elrepo.x86_64 升级内核完成
1.3K10编辑于 2024-10-31 - 来自专栏java学习java
一文打通锁升级（偏向锁，轻量级锁，重量级锁）
但是在JavaSE1.6的时候，对synchronized进行了优化，引入了偏向锁和轻量级锁，以及锁的存储结构和升级过程，减少了获取锁和释放锁的性能消耗，有些情况下它也就不那么重了。 synchronized锁升级 synchronized锁优化的背景： 用锁能实现数据的安全性，但是会带来性能下降。 无锁能够基于线程并行提升程序性能，但是会带来线程安全性下降。 synchronized锁:根据对象头的mark word 锁标志位来确定当前属于哪一种锁。 为什么会存在锁升级现象？ 一旦有第二个线程加入锁竞争，偏向锁就升级为轻量级锁（自旋锁）。 升级时机：当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁 假如线程A已经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁已经被线程A拿到，当前该锁已是偏向锁了。
69131编辑于 2023-10-15 - 来自专栏johnhuster
ReentrantReadWriteLock不存在锁升级，只存在锁降级
，这种情况就会出现死锁 试想一下：读锁与读锁之间不存在互斥的问题，读锁跟写锁互斥，互斥就是为了防止读数据期间临界区资源不被 修改，如果获取读锁后，同时其他线程也获取到了读锁，然后该线程试能成功获取写锁， **/ private void testUpgrade(){ //获取读锁 rl.lock(); //获取读锁 wl.lock(); wl.unlock() ; rl.unlock(); log.info("结束"); } /** 下面看下获取读锁后再获取写锁死锁的地方 **/ public final void acquire(int arg) { //tryAcquire失败后会进入acquireQueued方法，acquireQueued里面会不断调用tryAcquire方法试图获取写锁，但本文所说的情况下是不可能获得写锁的 = 0) //代码会走到这里，但是此时没有任何线程获取到写锁，所以getExclusiveOwnerThread()返回null，current线程为已经获取到试图获取写锁的线程
35320编辑于 2022-03-28
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号