第十二章：synchronized与锁升级

相关面试题

• 谈谈你对Synchronized的理解
• 请你聊聊Synchronized的锁升级
• Synchronized的性能是不是一定弱于Lock

锁优化背景

阿里巴巴规范：

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

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

Synchronized 锁性能变化

jdk5 以前

java5 以前，只有Synchronized，这个是操作系统级别的重量级操作。使用synchronized 时，需要用户态和内核态之间的切换

当我们在系统中执行一个程序时，大部分时间是运行在用户态下的，在其需要操作系统帮助完成某些它没有权力和能力完成的工作时就会切换到内核态

java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在用户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。

在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的==Mutex Lock（互斥锁）==来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因

复习：为什么任意一个对象都能成为锁？

Monitor可以理解为一种同步工具，也可理解为一种同步机制，常常被描述为一个Java对象。Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中 ，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。

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

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

1. 如果一个java对象被某个线程锁住，则该java对象的Mark Word字段中LockWord指向monitor的起始地址
2. Monitor的Owner字段会存放拥有相关联对象锁的线程id

synchronized 结合对象头：

对象头中的 MarkWorld 标志了该对象使用了哪种锁。

jdk6 之后

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

需要有个逐步升级的过程，别一开始就捅到重量级锁

synchronized的种类以及锁升级流程

多线程访问分三种情况：

• 只有一个线程来访问，有且唯一Only
• 有2个线程A、B来交替访问
• 竞争激烈，多个线程来访问

锁升级流程

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

不同种类的锁，锁指向不同：

• 偏向锁：MarkWord存储的是偏向的线程ID；
• 轻量锁：MarkWord存储的是指向线程栈中Lock Record的指针；
• 重量锁：MarkWord存储的是指向堆中的monitor对象的指针；

无锁

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

代码演示：

使用JOL查看无锁的MarkWord的分布图

public class JOLTest {
    public static void main(String[] args) {
        Object o = new Object();
        System.out.println( ClassLayout.parseInstance(o).toPrintable());
    }
}
1
2
3
4
5
6

从后往前看，每个字节从前往后读：

通过代码中，看出hashCode的值为0，这是因为只有在调用hashCode 方法时，才会在MarkWord中标记出来

输出二进制和十六进制看看对应关系：

此时 红色的 31 位就表示 hashCode 值，黄色部分是 十六进制表示。

偏向锁

是什么

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

作用

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

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

我们拿卖票的例子演示：

//第一步  创建资源类，定义属性和和操作方法
class LTicket {
    //票数量
    private int number = 30;

    //创建可重入锁
    private final ReentrantLock lock = new ReentrantLock();
    //卖票方法
    public void sale() {
        //上锁
        lock.lock();
        try {
            //判断是否有票
            if(number > 0) {
                System.out.println(Thread.currentThread().getName()+" ：卖出"+(number--)+" 剩余："+number);
            }
        } finally {
            //解锁
            lock.unlock();
        }
    }
}

public class Demo07 {
    //第二步 创建多个线程，调用资源类的操作方法
    //创建三个线程
    public static void main(String[] args) {

        LTicket ticket = new LTicket();

        new Thread(()-> {
            for (int i = 0; i < 40; i++) {
                ticket.sale();
            }
        },"AA").start();

        new Thread(()-> {
            for (int i = 0; i < 40; i++) {
                ticket.sale();
            }
        },"BB").start();

        new Thread(()-> {
            for (int i = 0; i < 40; i++) {
                ticket.sale();
            }
        },"CC").start();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

几乎所有的票都是 CC 卖出的，其实这段同步代码一直都被 CC 访问。这时候就会出现 偏向锁

AA ：卖出30 剩余：29
AA ：卖出29 剩余：28
AA ：卖出28 剩余：27
CC ：卖出27 剩余：26
CC ：卖出26 剩余：25
CC ：卖出25 剩余：24
CC ：卖出24 剩余：23
CC ：卖出23 剩余：22
CC ：卖出22 剩余：21
CC ：卖出21 剩余：20
CC ：卖出20 剩余：19
CC ：卖出19 剩余：18
CC ：卖出18 剩余：17
CC ：卖出17 剩余：16
CC ：卖出16 剩余：15
CC ：卖出15 剩余：14
CC ：卖出14 剩余：13
CC ：卖出13 剩余：12
CC ：卖出12 剩余：11
CC ：卖出11 剩余：10
CC ：卖出10 剩余：9
CC ：卖出9 剩余：8
CC ：卖出8 剩余：7
CC ：卖出7 剩余：6
CC ：卖出6 剩余：5
CC ：卖出5 剩余：4
CC ：卖出4 剩余：3
CC ：卖出3 剩余：2
CC ：卖出2 剩余：1
CC ：卖出1 剩余：0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

小总结

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

多线程的情况下，锁不仅不存在多线程竞争，还存在锁由同一线程多次获得的情况，

偏向锁就是在这种情况下出现的，它的出现是为了解决只有在一个线程执行同步时提高性能。

备注

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

偏向锁的持有

理论落地

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

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

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

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

  • 竞争成功，表示之前的线程不存在了，MarkWord里面的线程ID为新线程的ID，锁不会升级，仍然为偏向锁；
  • 竞争失败，这时候可能需要升级变为轻量级锁，才能保证线程间公平竞争锁。

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

技术实现

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

举例说明：

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

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

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

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

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

偏向锁 JVM 参数说明

通过 java -XX:+PrintFlagsInitial |grep BiasedLock* （需要在Linux环境下使用，用git也可以）该指令可以看出 偏向锁的相关参数。

• -XX:BiasedLockingStartupDelay 偏向锁的延迟时间，默认是 4s ，也就是说偏向锁是默认开启的，但是在启动程序后有 4s 的延迟
• -XX:+UseBiasedLocking 开启偏向锁，默认是 开启的。
  • 如果关闭偏向锁，直接进入轻量级锁状态。

程序中想要使用偏向锁：

• 程序运行时间超过4s，或者 sleep
• 增加JVM参数将延迟时间改为0： -XX:BiasedLockingStartupDelay=0

代码演示没有加任何 JVM 参数的情况：

未加任何参数情况下，锁的状态标志位是 000，因为偏向锁有延迟时间。

代码演示增加JVM参数 -XX:BiasedLockingStartupDelay=0

此时锁状态标志位为 101——偏向锁

多线程环境下

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

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

撤销锁的流程：

偏向锁使用一种等到竞争出现才释放锁的机制，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。

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

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

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

总结

jdk15 以后偏向锁已经被废弃了，原因就是：偏向锁维护起来耗时耗神

轻量级锁

多线程竞争，但是任意时刻最多只有一个线程竞争（其他线程自旋），即不存在锁竞争太过激烈的情况，也就没有线程阻寨

• 有线程来参与锁的竞争，但是获取锁的冲突时间极短
• 本质就是自选锁CAS

64 位图：

轻量级锁的获取

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

主要目的： 在没有多线程竞争的前提下，通过CAS减少重量级锁使用操作系统互斥锁产生的性能消耗，说白了先自旋再阻塞。
升级时机： 当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁

假如线程A已经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁已经被线程A拿到，当前该锁已是偏向锁了。
而线程B在争抢时发现对象头Mark Word中的线程ID不是线程B自己的线程ID(而是线程A)，那线程B就会进行CAS操作希望能获得锁。

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

如果锁获取成功，直接替换Mark Word中的线程ID为B自己的ID(A → B)，重新偏向于其他线程(即将偏向锁交给其他线程，相当于当前线程"被"释放了锁)，该锁会保持偏向锁状态，A线程Over，B线程上位；

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

轻量级锁的加锁

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

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

轻量级锁的释放

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

代码演示轻量级锁

设置JVM参数：-XX:-UseBiasedLocking 关闭偏向锁

自适应锁

自适应锁就是自适应的自旋锁，自旋的时间不是固定时间，而是由前一次在同一个锁上的自旋时间和锁的持有者状态来决定。

简单来说就是当使用轻量级锁时，线程自旋的次数太多或达到一定程度后，就会自适应

轻量级锁和偏向锁的区别

• 争夺轻量级锁失败时，自旋尝试抢占锁。偏向锁只有一个线程执行。
• 轻量级锁每次退出同步块都需要释放锁，而偏向锁是在竞争发生时才释放锁

重锁

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

64位图：

重锁原理

Java中synchronized的重量级锁，是基于进入和退出Monitor对象实现的。在编译时会将同步块的开始位置插入monitor enter指令，在结束位置插入monitor exit指令。

当线程执行到monitor enter指令时，会尝试获取对象所对应的Monitor所有权，如果获取到了，即获取到了锁，会在Monitor的owner中存放当前线程的id，这样它将处于锁定状态，除非退出同步块，否则其他线程无法获取到这个Monitor。

代码演示：

总结

锁升级与hashCode的关系

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

在无锁状态下，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，锁释放后也会将信息写回到对象头。

轻量级锁和重量级锁都有额外的空间来保存 MarkWord （hashCode，GC年龄…）中的信息，当锁释放时，将信息写回 MarkWord中。

一：当对象获取偏向锁之前计算过hashCode值，就无法进入偏向锁，而是跳过偏向锁进入轻量级锁（代码演示一）。

二：当对象处于偏向锁时，此时计算hashCode值，偏向锁会膨胀为重量级锁（代码演示二）。

代码演示一：

代码演示二：

各类锁的优缺点

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

synchronized锁升级过程总结：一句话，就是先自旋，不行再阻塞。
实际上是把之前的悲观锁(重量级锁)变成在一定条件下使用偏向锁以及使用轻量级(自旋锁CAS)的形式

synchronized在修饰方法和代码块在字节码上实现方式有很大差异，但是内部实现还是基于对象头的MarkWord来实现的。
JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁->偏向锁->轻量级锁->重量级锁的升级过程，而不是无论什么情况都使用重量级锁。

锁消除

学过jvm的应该清楚，基于逃逸分析的同步省略，就是省略代码块中无用的 synchronized ，也是jvm一种优化手段。这个锁消除和同步策略一样

代码演示：

public class LockClearUPDemo {
    static Object objectLock = new Object();//正常的

    public void m1() {
        //锁消除,JIT会无视它，
        // 每个对象都有 o 对象，加锁已经无意义了；
        Object o = new Object();

        synchronized (o) {
            System.out.println("-----hello LockClearUPDemo" + "\t" + o.hashCode() + "\t" + objectLock.hashCode());
        }
    }

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

        for (int i = 1; i <= 10; i++) {
            new Thread(() -> {
                demo.m1();
            }, String.valueOf(i)).start();
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

锁粗化

假如方法中首位相接，前后相邻的都是同一个锁对象，那JIT编译器就会把这几个synchronized块合并成一个大块，

加粗加大范围，一次申请使用即可，避免次次都申请和释放锁，提升了性能

代码演示：

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


    public static void main(String[] args)
    {
        new Thread(() -> {
            synchronized (objectLock) {
                System.out.println("11111");
            }
            synchronized (objectLock) {
                System.out.println("22222");
            }
            synchronized (objectLock) {
                System.out.println("33333");
            }
            
            // 以上代码会被替换成以下代码》。。。
            synchronized (objectLock) {
                System.out.println("11111");
                System.out.println("22222");
                System.out.println("33333");
            }
        },"a").start();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

---

---

各位彭于晏，如有收获点个赞不过分吧…✌✌✌

---

gongzhonghao 回复 [JUC] 获取MarkDown笔记