JUC并发编程第十一章——Synchronized与锁升级机制

标签：JUC synchronized Synchronized 编程 剩下 线程 轻量级 卖出 偏向

1 入门知识介绍

synchronized锁，是不是默认实现了锁升级。代码中只需要直接使用synchronized，至于怎么从偏向锁升级为轻量锁再升级为重量级锁，这些底层jvm已经实现了。不需要程序员担心。

---

是的，Java 8中的synchronized关键字确实默认实现了锁升级的机制。当使用synchronized关键字时，JVM会自动管理锁的状态，根据竞争情况从偏向锁开始，逐步升级到轻量级锁，最终升级到重量级锁。这一过程是由JVM内部实现的，不需要程序员手动干预。

锁升级的过程如下：

1. 偏向锁（Biased Locking）：在没有竞争的情况下，JVM使用偏向锁来减少锁操作的开销。当一个线程第一次获取到锁时，该锁会偏向这个线程，后续这个线程再次访问这个同步块时，不需要任何同步操作，因为锁已经被该线程偏向了。

2. 轻量级锁（Lightweight Locking）：如果有另一个线程尝试获取这个锁，JVM会将偏向锁撤销，并升级为轻量级锁。轻量级锁通过在栈帧中存储锁记录（Lock Record）的方式来实现，线程通过CAS（比较并交换）操作尝试将锁的Mark Word更新为指向自己的锁记录的指针，以此来获取锁。

3. 重量级锁（Heavyweight Locking）：如果锁竞争加剧，轻量级锁的自旋操作不能及时成功获取锁，JVM会将轻量级锁膨胀为重量级锁。此时，线程会被阻塞，直到拥有锁的线程释放锁后，操作系统才会唤醒等待的线程。

这种锁升级的机制是JVM为了提高同步性能而设计的，它能够在没有竞争或竞争不激烈的情况下，减少同步操作的开销，而在竞争激烈时又能确保同步的正确性。

因此，作为Java程序员，你只需要在代码中使用synchronized关键字来同步代码块或方法，而无需关心锁的具体状态和升级过程。JVM会自动处理这些细节，以优化程序的性能。

1.1 面试题

• 谈谈你对Synchronized的理解

• 请你聊聊Synchronized的锁升级

1.2 本章路线总纲

1.2.1 锁使用的强制要求

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

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

• synchronized锁优化的背景

  用锁能够实现数据的安全性，但是会带来性能下降。

  无锁能够基于现成并行提升程序性能，但是会带来安全性下降

  那么如何求平衡？

• 锁的升级过程

  无锁-偏向锁-轻量级锁-重量级锁(锁的范围一点一点变大，还是上面那句话，尽可能锁的范围小)

1.2.2 synchronized锁：由对象头重的Mark Word根据锁标志位的不同而被复用及锁升级策略

2 Synchronized的性能变化

java5以前，只有Synchronized，这个是操作系统级别的重量级操作

重量级锁，假如锁的竞争比较激烈的话，性能下降

Java5之前，用户态和内核态之间的切换

(我们写一个new Thread().start()的话是调用了底层的native方法的）

• java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在用户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。
• 在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock(系统互斥量)来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁

（一句话就是尽量减少用户态和内核态的切换）

为什么每一个对象都可以成为一个锁-复习之前的知识

markOop.hpp

我们大概可以知道，每个对象都有一个ObjectMonitor，而每个ObjectMonitor都可以成为锁。

小结：我们说在java中每个对象都可以成为一把锁，因为在JVM中每个对象都一个monitor(监视器锁。对应到C底层叫做Object Monitor，并用c定义了很多信息。再往下到操作系统中是基于Mutex Lock互斥锁实现，涉及到了用户态和内核态的切换，所以非常耗费资源。

结合之前的synchronized和对象头说明

• 主要就是MarkWord中是什么代码表示了它是什么锁状态

从图中可以看出，如果当前锁对象是重量级锁，它底层还会有ObjectMonitor，保存了很多锁的相关信息。

---

3 Synchronized锁种类及升级步骤

3.1 多线程访问情况

• 只有一个线程来访问，有且唯一Only One
• 有两个线程（2个线程交替访问）
• 竞争激烈，更多线程来访问

不同线程访问情况，有着不同锁解决问题。

3.2 升级流程

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

• 重点关注【偏向锁位】和【锁标志位】

锁指向总结，请牢记

• 偏向锁：MarkWord存储的是偏向的线程ID；

• 轻量锁：MarkWord存储的是指向线程栈中Lock Record的指针；

• 重量锁：MarkWord存储的是指向堆中的monitor对象的指针；

---

3.3 无锁

复习C源码的MarkWord标记

我们知道，一个对象只是创建出来，它是无锁状态的。无锁状态的MarkWord标记占8字节，也就是64位。其中：25位是没有使用的 (unused)，31位存放了hashcode (hash)，1位未使用，4位是分代年龄 (age 4位二进制最大就是1111，十进制就是15，因此分代年龄最大15)，1位偏向锁位 (biased lock)，2位锁标识位 (normal lock)。25 + 31 + 1 + 4 + 1 + 2 = 64位(8字节)

Code1

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo {

    public static void main(String[] args) {
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }

}

输出结果：
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

提出疑问

以上Code1就是new一个对象，对应64位对象标记图的无锁态！

1. hashCode对应的是哪31位，为什么都是0？
2. 前8个字节（64位）的对象标记应该正着看还是倒着看？

Code2

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo {

    public static void main(String[] args) {
        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()));

        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }

}

输出结果：
10进制：529116035
16进制：1f89ab83
2进制：11111100010011010101110000011
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 83 ab 89 (00000001 10000011 10101011 10001001) (-1985248511)
      4     4        (object header)                           1f 00 00 00 (00011111 00000000 00000000 00000000) (31)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

解答疑问

        1.可以看到调用了hashCode()方法后，对象标记打印出了对象的hashCode，所以默认是不打印hashCode的，需要调用对象的hashCode()方法才会打印

        2.倒着看的，且每8位正着看，可以看到16进制hashCode刚好对应倒着看的对象标记的31位的hashCode（1f89ab83）

        二进制验证
                二进制：11111100010011010101110000011
                对应对象标记：00011111 10001001 10101011 10000011 ——>（第一位未使用）——>

0011111 10001001 10101011 10000011 ——> 11111 10001001 10101011 10000011 (二进制打印结果)
        3.另外，无锁态的对象标志对应这里的具体如下：

程序不会有锁得竞争

无锁：初始状态，一个对象被实例化后，如果还没有被任何线程竞争锁，那么它就为无锁状态（001）

3.4 偏向锁

3.4.1 偏向锁：单线程竞争

当线程A第一次竞争到锁时，通过修改Mark Word中的偏向线程ID、偏向模式。如果不存在其他线程竞争，那么持有偏向锁的线程将永远不需要进行同步

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

例如：同一个老顾客来访，直接老规矩行方便

多线程卖票案例

public class SaleTicketDemo {

    public static void main(String[] args) {
        Ticket ticket = new Ticket();

        new Thread(() -> {
            for (int i = 0; i < 55; i++) {
                ticket.sale();
            }
        }, "a").start();
        new Thread(() -> {
            for (int i = 0; i < 55; i++) {
                ticket.sale();
            }
        }, "b").start();
        new Thread(() -> {
            for (int i = 0; i < 55; i++) {
                ticket.sale();
            }
        }, "c").start();
    }

}

class Ticket {

    private int number = 50;

    Object lockObject = new Object();

    public void sale() {
        synchronized (lockObject) {
            if (number > 0) {
                System.out.println(Thread.currentThread().getName() + "卖出第：\t" + (number--) + "\t 还剩下：" + number);
            }
        }
    }

}

输出结果：
a卖出第：	50	 还剩下：49
a卖出第：	49	 还剩下：48
a卖出第：	48	 还剩下：47
a卖出第：	47	 还剩下：46
a卖出第：	46	 还剩下：45
a卖出第：	45	 还剩下：44
b卖出第：	44	 还剩下：43
b卖出第：	43	 还剩下：42
b卖出第：	42	 还剩下：41
a卖出第：	41	 还剩下：40
a卖出第：	40	 还剩下：39
a卖出第：	39	 还剩下：38
a卖出第：	38	 还剩下：37
a卖出第：	37	 还剩下：36
a卖出第：	36	 还剩下：35
a卖出第：	35	 还剩下：34
a卖出第：	34	 还剩下：33
a卖出第：	33	 还剩下：32
a卖出第：	32	 还剩下：31
a卖出第：	31	 还剩下：30
a卖出第：	30	 还剩下：29
a卖出第：	29	 还剩下：28
a卖出第：	28	 还剩下：27
a卖出第：	27	 还剩下：26
a卖出第：	26	 还剩下：25
a卖出第：	25	 还剩下：24
a卖出第：	24	 还剩下：23
a卖出第：	23	 还剩下：22
a卖出第：	22	 还剩下：21
a卖出第：	21	 还剩下：20
a卖出第：	20	 还剩下：19
a卖出第：	19	 还剩下：18
a卖出第：	18	 还剩下：17
a卖出第：	17	 还剩下：16
a卖出第：	16	 还剩下：15
a卖出第：	15	 还剩下：14
a卖出第：	14	 还剩下：13
a卖出第：	13	 还剩下：12
a卖出第：	12	 还剩下：11
a卖出第：	11	 还剩下：10
a卖出第：	10	 还剩下：9
a卖出第：	9	 还剩下：8
a卖出第：	8	 还剩下：7
a卖出第：	7	 还剩下：6
a卖出第：	6	 还剩下：5
a卖出第：	5	 还剩下：4
a卖出第：	4	 还剩下：3
a卖出第：	3	 还剩下：2
a卖出第：	2	 还剩下：1
a卖出第：	1	 还剩下：0

从运行结果可以看出：大部分情况下都是某一个线程进入同步代码块。这样大大减少了用户态切换到内核态的次数 (synchronized锁是重量级锁，设计底层操作系统，会从用户态切换为内核态。而通过偏锁优化以后，同一个线程再次进入该同步代码块时，不需要再次加锁和释放锁)！提高程序性能！

结论
HotSpot的作者经过研究发现，大多数情况下：

        在多线程情况下，锁不仅不存在多线程竞争，还存在由同一个线程多次获得的情况，偏向锁就是在这种情况下出现的，它的出现是为了解决只有一个线程执行同步时提高性能。

        偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他线程访问，则持有偏向锁的线程将永远不需要触发同步。也即偏向锁在资源在没有竞争情况下消除了同步语句，懒得连CAS操作都不做了，直接提高程序性能。

---

3.4.2 偏向锁的持有

理论落地：

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

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

判断当前线程ID和偏向锁记录的ID是否相等：

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

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

• 竞争成功，表示之前的线程不存在了，MarkWord里面的线程1D为新线程的ID，锁不会升级，仍然为偏向锁；
• 竞争失败，说明当前锁还是被其他线程持有。需要升级变为轻量级锁，才能保证线程间公平竞争锁。（偏向锁 ——>(升级为) 轻量级锁）

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

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

偏向锁用54位存放线程指针以确定是哪个线程占有了锁。

---

3.4.3 细化Account对象举例说明

结论：JVM不用和操作系统协商设置Mutex（争取内核，内核态的切换），它只需要记录下线程ID就标识自己获得了当前锁，不用操作系统接入。

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

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

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

结论：JVM不用和操作系统协商设置Mutex（争取内核），它只需要记录下线程ID就表示自己获得了当前锁，不用操作系统介入

上述就是偏向锁：在没有其它线程竞争的时候，一直偏向当前线程，当前线程可以一直执行

---

3.4.4 偏向锁JVM命令

java -XX:+PrintFlagsInitial |grep BiasedLock*

• 偏向锁存在且默认开启（图片里最后一行的false），并且有4s延迟（图片里的4000）

重要参数说明

• 关于如何开启偏向锁（延迟设置为0即可）和关闭偏向锁

实际上偏向锁在JDK1.6之后是款认开启的，但是启动时间有延迟，
所以需要添加参数-XX:BiasedLockingStartupDelay=0，让其在程序启动时立刻启动。

开启偏向锁：
-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0

关闭偏向锁：关闭之后程序默认会直接进入 ----------------------->>>>>>> 轻量级锁状态
-XX:-UseBiasedLocking

Code演示-通过将延迟改为0来开启偏向锁

默认情况下

• 演示无效果，偏向锁本应该是101，000是轻量级锁（无效是因为有4s延迟，程序直接变成了轻量级锁）

因为参数系统默认开启

说明：默认情况下，jvm会延迟4s再开启偏向锁。这就说明，虚拟机刚启动时，是没有偏向锁的，就会自动升级为轻量级锁。

关闭延迟参数，启用该功能

Code演示2-主动迎合这4秒的延迟

主动迎合4秒的延迟

---

第一种情况-没用synchronized

• 确实开启了偏向锁101，但是o对象未采用synchronized加锁，所以线程id是空的

第二种情况- 用synchronized

• 使用synchronized锁住o之后，发现这五十四位指向了当前线程指针

可以发现，当使用了synchronized以后，对象o记录了当前持有锁的线程。

---

3.4.5 偏向锁 升级为 轻量级锁

首先我们知道：当只有一个线程使用锁资源，没有人跟他争抢锁的时候，这个锁对象的锁状态是：偏向锁。

现在偏向锁的好日子到头了，另一个线程尝试获取锁。锁对象保存了之前线程的ID，和当前尝试获取锁的线程ID进行对比：

1. 如果相等那还好说，说明锁就是当前线程的。还是偏向锁，直接进入就行。
2. 问题就怕不是同一个线程！发生了竞争。这时候当前尝试获取锁的线程如果争抢成功，说明之前持有锁的线程不在了，当前线程成功获取锁。
3. 但如果当前线程发现还是有线程持有锁，这个锁就会从偏向锁升级为轻量级锁。以确保线程公平竞争锁。

偏向锁的撤销

• 当有另外线程逐步来竞争所的时候，就不能再使用偏向锁了，要升级为轻量级锁

• 竞争线程尝试CAS更新对象头失败，会等待到全局安全点（stop-the-world 此时不会执行任何代码）撤销偏向锁

撤销

偏向锁使用一种等到竞争出现才释放锁的机制 (因为这个时候要发生锁升级了)，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。

撇销需要等待全局安全点(该时间点上没有字节码正在执行)，同时检查持有偏向锁的线程是否还在执行：

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

②第一个线程执行完成synchronized方法(退出同步块)，则将对象头设置成无锁状态并撤销偏向锁，重新偏向。（锁又成了无主状态，所有线程公平竞争）

---

3.4.6 总体步骤流程图示

题外话 

Java15逐步废弃偏向锁，需要手动开启。因为偏向锁开销大，废成本

---

3.5 轻量锁

是什么

轻量级锁：多线程竞争，但是任意时刻最多只有一个线程竞争，即不存在锁竞争太过激烈的情(竞争太激烈就要升级为重量级锁了)，也就没有线程阻寨

主要作用

• 有线程来参与锁的竞争，但是获取锁的冲突时间极短

• 本质就是自旋锁CAS

再看64位标记图

轻量级锁的获取

• 轻量级锁是为了在线程近乎交替执行同步块时提高性能。
• 近乎交替指的是：两个线程轮流获取锁，线程a刚释放锁，线程b恰好来获取锁，线程b刚释放锁，线程a恰好来获取锁。两个线程基本上没有竞争锁的情况。

主要目的：

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

偏向锁升级为轻量锁的时机：

• 当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁
• 假如线程A己经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁己经被线程A拿到，当前该锁己是偏向锁了。
• 而线程B在争抢时发现对象头Mark中的线程ID不是线程B自己的线程ID(而是线程A)，那线程B就会进行CAS操作希望能获得锁。此吋线程B操作中有两种情况：
• 如果锁获取成功，直接替换Mark Word中的线程ID为B自己的ID(A—B)．重新偏向于其他线程(即将偏向锁交给其他线程，相当于当前线程"被"释放了锁)，该锁会保持偏向锁状态，A线程Over，B线程上位：

• 如果锁获取失败，则偏向锁升级为轻量级锁(设置偏向锁标识为0并设置锁标志位为00)，此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁。

轻量级锁的加锁

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

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

轻量级锁的释放

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

标签：JUC,synchronized,Synchronized,编程,剩下,线程,轻量级,卖出,偏向
From： https://blog.csdn.net/qq_64064246/article/details/139626931