bilibili尚硅谷周阳老师JUC并发编程与源码分析课程笔记第十一章—

文章目录

- 先从阿里及其它大厂面试题说起
- 本章路线总纲
- - 阿里手册对锁使用的强制要求
  - Synchronized锁优化的背景
  - Synchronized锁的升级过程
  - Synchronized锁的升级标志
- Synchronized的性能变化
- - Java5以前，只有Synchronized，这个是操作系统级别的重量级锁
  - 为什么每一个对象都可以成为一个锁？？？
  - - C语言底层源码markOop.hpp
    - Monitor（监视器锁）
    - 结合之前的synchronized和对象头说明
  - java6开始，优化Synchronized
- Synchronized锁种类及升级步骤
- - 3种多线程访问情况
  - 升级流程
  - - 再看64位对象标记图
    - 锁指向，请牢记
  - 无锁
  - - 复习C源码的MarkWord的标记
    - Code1
    - 提出疑问
    - Code2
    - 解答疑问
    - 程序不会有锁得竞争
  - 偏锁
  - - 是什么
    - 主要作用
    - 多线程买票案例
    - - 结论
    - 偏向锁的持有
    - - 理论
      - 技术实现
      - 细化案例Account对象举例说明
    - 偏向锁JVM命令
    - - jdk8偏向锁JVM命令执行结果
      - 重要参数解释
        重要参数使用
    - Code演示
    - - 一切按照默认
      - 方式一：偏向锁启动延迟设置为0
      - 方式二：程序启动后暂停大于4s
    - Code演示2
    - - 测试锁状态为偏向锁的对象的对象标记前54位是不是存储当前线程指针
    - 好日子到头了，开始有第2个线程来抢夺了
    - 偏向锁的撤销
    - 题外话
  - 轻锁
  - - 是什么
    - 主要作用
    - 再看64位对象标记图
    - 轻量锁的获取
    - Code演示
    - 自旋一定程度和次数
    - - Java6之前（了解即可）
      - Java6之后
    - 轻量锁和偏向锁的区别
  - 重锁
  - - 是什么
    - 再看64位对象标记图
    - 重量级锁的原理
    - Code演示
  - 小总结
  - - 锁升级的过程总体步骤流程图
    - 还有疑问
    - - 锁升级发生后，hashcode去哪儿了?
      - Code演示
      - Code演示2
      - Code演示3
    - 锁优缺点对比
    - synchronized锁升级和实现原理
- JIT编译器对锁的优化
- - JIT
  - 锁消除
  - - Code演示
    - 说明
  - 锁粗化
  - - Code演示
    - 说明
- 小总结

先从阿里及其它大厂面试题说起

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

本章路线总纲

阿里手册对锁使用的强制要求

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

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

Synchronized锁优化的背景

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

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

求平衡？？？

Synchronized锁的升级过程

在这里插入图片描述

Synchronized锁的升级标志

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

Synchronized的性能变化

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

重量级锁，假如锁的竞争比较激烈的话，性能下降
Java 5之前用户态和内核态之间的转换

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

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

为什么每一个对象都可以成为一个锁？？？

C语言底层源码markOop.hpp

在这里插入图片描述

Monitor（监视器锁）

复习之前的ObjectMonitor

在这里插入图片描述

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

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

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

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

在这里插入图片描述

java6开始，优化Synchronized

Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁。需要有个逐步升级的过程，别一开始就捅到重量级锁！！！

Synchronized锁种类及升级步骤

3种多线程访问情况

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

升级流程

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

再看64位对象标记图

在这里插入图片描述

锁指向，请牢记

偏向锁：MarkWord存储的是偏向的线程ID
轻量锁：MarkWord存储的是指向线程栈中Lock Record的指针
重量锁：MarkWord存储的是指向堆中的monitor对象（系统互斥量指针）

无锁

复习C源码的MarkWord的标记

在这里插入图片描述

ps：对应上面64位对象标记图

Code1

package com.bilibili.juc.syncup;

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位对象标记图的无锁态！

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

Code2

package com.bilibili.juc.syncup;

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

解答疑问

可以看到调用了hashCode()方法后，对象标记打印出了对象的hashCode，所以默认是不打印hashCode的，需要调用对象的hashCode()方法才会打印
倒着看的，且每8位正着看，可以看到16进制hashCode刚好对应倒着看的对象标记的31位的hashCode（1f89ab83）
- 二进制验证
  - 2进制：11111100010011010101110000011
  - 对应对象标记：0011111100010011010101110000011 ——> 11111100010011010101110000011
另外，无锁态的对象标志对应这里的具体如下：

前25位unused	31位hash	1位unused	4位分代年龄	1位偏向锁位	后2位锁标志位
00000000 00000000 00000000 0	0011111 10001001 10101011 10000011	0	0000	0	01

程序不会有锁得竞争

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

偏锁

是什么

偏向锁：单线程竞争

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

主要作用

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

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

多线程买票案例

package com.bilibili.juc.syncup;

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

可以看到输出结果中，大多数都是a线程抢到锁！这样大大减少了用户态切换到内核态的次数！提高程序性能！

结论

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

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

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

偏向锁的持有

理论

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

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

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

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

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

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

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

技术实现

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

在这里插入图片描述

细化案例Account对象举例说明

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

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

在这里插入图片描述

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

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

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

偏向锁JVM命令

java -XX:+PrintFlagsInitial | grep BiasedLock*：查看jvm虚拟机启动后涉及到偏向锁的内容

jdk8偏向锁JVM命令执行结果

在这里插入图片描述

重要参数解释

product：官方支持，JVM内部选项，表示可以在生产上使用

bool UseBiasedLocking = true：默认开启偏向锁

intx BiasedLockingStartupDelay = 4000：偏向锁启动有延迟，默认4s（想要看到偏向锁产生的效果两种方法：1.将延迟时间修改为0s，2.程序启动时，线程休眠时间超过4s）

重要参数使用

在这里插入图片描述

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

开启偏向锁，并设置延迟为0：

-XX:+UseBiasedLocking XX:BiasedLockingStartupDelay=0

关闭偏向锁（关闭之后程序默认会直接进入——>轻量级锁）：

-XX:-UseBiasedLocking

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

Code演示

一切按照默认

package com.bilibili.juc.syncup;

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo2 {

    public static void main(String[] args) {
        Object o = new Object();

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

}

输出结果：
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           d8 f4 1f 1c (11011000 11110100 00011111 00011100) (471856344)
      4     4        (object header)                           17 00 00 00 (00010111 00000000 00000000 00000000) (23)
      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

提出疑问：可以看到最后三位是000，是轻量级锁，为什么？

解答疑问：因为虽然偏向锁是默认开启的，但是默认延迟是4s，所以在这延迟4s中偏向锁是关闭的，所以是轻量级锁

方式一：偏向锁启动延迟设置为0

在这里插入图片描述

package com.bilibili.juc.syncup;

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo2 {

    public static void main(String[] args) {
        Object o = new Object();

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

}

输出结果：
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 98 00 c1 (00000101 10011000 00000000 11000001) (-1056925691)
      4     4        (object header)                           3c 02 00 00 (00111100 00000010 00000000 00000000) (572)
      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

可以看到最后三位是101，是偏向锁

方式二：程序启动后暂停大于4s

package com.bilibili.juc.syncup;

import org.openjdk.jol.info.ClassLayout;

import java.util.concurrent.TimeUnit;

public class SynchronizedUpDemo2 {

    public static void main(String[] args) {
        try {
            TimeUnit.SECONDS.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        Object o = new Object();

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

}

输出结果：
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 b9 b6 59 (00000101 10111001 10110110 01011001) (1505147141)
      4     4        (object header)                           0c 02 00 00 (00001100 00000010 00000000 00000000) (524)
      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

可以看到最后三位是101，是偏向锁

Code演示2

测试锁状态为偏向锁的对象的对象标记前54位是不是存储当前线程指针

package com.bilibili.juc.syncup;

import org.openjdk.jol.info.ClassLayout;

import java.util.concurrent.TimeUnit;

public class SynchronizedUpDemo3 {

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

}

输出结果：
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)
      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

----------------------------
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 b9 a4 76 (00000101 10111001 10100100 01110110) (1990506757)
      4     4        (object header)                           d4 01 00 00 (11010100 00000001 00000000 00000000) (468)
      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

可以看到：

在-以上没有使用synchronized，所以前54位是00000000 00000000 00000000 00000000 00000000 00000000 000000，没有存放当前线程指针；

在-以下使用了synchronized，所以前54位是00000000 00000000 00000001 11010100 01110110 10100100 101110，存放当前线程指针

好日子到头了，开始有第2个线程来抢夺了

偏向锁的撤销

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

偏向锁使用一种等到竞争出现才释放锁的机制，只有当其它线程竞争锁时，持有偏向锁的原来线程才会被撤销。竞争线程尝试CAS更新对象头失败，会等到全局安全点（此时不会执行任何代码，没有字节码正在执行）撤销偏向锁，同时检查持有偏向锁的线程是否还在执行

具体情况分析：

第一个线程正在执行Synchronized方法（处于同步块），它还没有执行完，其他线程来抢夺，该偏向锁会被取消掉并出现锁升级，此时轻量级锁由原来持有偏向锁的线程持有，继续执行同步代码块，而正在竞争的线程会自动进入自旋等待获得该轻量级锁
第一个线程执行完Synchronized方法（退出同步块），则将对象头设置为无锁状态并撤销偏向锁，重新偏向

在这里插入图片描述

题外话

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

本课程以Java8为主，下面是特例版本，Java15的官网说明：

在这里插入图片描述

轻锁

是什么

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

主要作用

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

再看64位对象标记图

在这里插入图片描述

轻量锁的获取

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

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

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

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

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

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

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

轻量级锁的加锁

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

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

轻量级锁的释放

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

Code演示

如果关闭偏向锁，就可以直接进入轻量级锁

-XX:-UseBiasedLocking

package com.bilibili.juc.syncup;

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo4 {

    public static void main(String[] args) {
        Object o = new Object();

        new Thread(() -> {
            synchronized (o) {
                System.out.println(ClassLayout.parseInstance(o).toPrintable());
            }
        }, "t1").start();
    }

}

输出结果：
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           80 f2 bf 3c (10000000 11110010 10111111 00111100) (1019212416)
      4     4        (object header)                           f0 00 00 00 (11110000 00000000 00000000 00000000) (240)
      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

自旋一定程度和次数

Java6之前（了解即可）

默认启用，默认情况下自旋的次数是10次（可以用-XX:PreBlockSpin=10来修改）

或者自旋线程数超过cpu核数一半

Java6之后

Java6之后是自适应自旋锁

自适应自旋锁的大致原理

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

线程如果自旋成功了，那下次自旋的最大次数会增加，因为JVM认为既然上次成功了，那么这一次也大概率会成功
如果很少会自旋成功，那么下次会减少自旋的次数甚至不自旋，避免CPU空转

轻量锁和偏向锁的区别

争夺轻量锁失败时，自旋尝试抢占锁

轻量级锁每次退出同步块都需要释放锁，而偏向锁是在竞争发生时才释放锁

重锁

是什么

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

再看64位对象标记图

在这里插入图片描述

重量级锁的原理

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

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

Code演示

package com.bilibili.juc.syncup;

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo5 {

    private static Object objectLock = new Object();

    public static void main(String[] args) {
        new Thread(() -> {
            synchronized (objectLock) {
                System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
            }
        }, "t1").start();

        new Thread(() -> {
            synchronized (objectLock) {
                System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
            }
        }, "t2").start();

        new Thread(() -> {
            synchronized (objectLock) {
                System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
            }
        }, "t3").start();

        new Thread(() -> {
            synchronized (objectLock) {
                System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
            }
        }, "t4").start();
    }

}

输出结果：
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           fa 45 dd ab (11111010 01000101 11011101 10101011) (-1411561990)
      4     4        (object header)                           cb 01 00 00 (11001011 00000001 00000000 00000000) (459)
      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

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           fa 45 dd ab (11111010 01000101 11011101 10101011) (-1411561990)
      4     4        (object header)                           cb 01 00 00 (11001011 00000001 00000000 00000000) (459)
      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

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           fa 45 dd ab (11111010 01000101 11011101 10101011) (-1411561990)
      4     4        (object header)                           cb 01 00 00 (11001011 00000001 00000000 00000000) (459)
      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

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           fa 45 dd ab (11111010 01000101 11011101 10101011) (-1411561990)
      4     4        (object header)                           cb 01 00 00 (11001011 00000001 00000000 00000000) (459)
      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

可以看到最后两位是10，是重量级锁

小总结

锁升级的过程总体步骤流程图

下图中红线流程部分为偏向锁获取和撤销过程：

在这里插入图片描述

ps：图片来源于百度，若侵权，联系我删除

还有疑问

锁升级发生后，hashcode去哪儿了?

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

用书中的一段话来描述锁和hashcode之间的关系：

在这里插入图片描述

上面这段话的翻译：

在无锁状态下，Mark Word中可以存储对象的identity hash code值。当对象的hashCode()方法第一次被调用时，JVM会生成对应的dentity 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保存的重量级锁指针，代表重量级锁的ObiectMonitor类里有字段记录非加锁状态下的Mark Word，锁释放后也会将信息写回到对象头

Code演示

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

package com.bilibili.juc.syncup;

import org.openjdk.jol.info.ClassLayout;

import java.util.concurrent.TimeUnit;

public class SynchronizedUpDemo6 {

    public static void main(String[] args) {
        // 先睡眠5s，保证开启偏向锁
        try {
            TimeUnit.SECONDS.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        Object o = new Object();
        System.out.println("本应是偏向锁");
        System.out.println(ClassLayout.parseInstance(o).toPrintable());

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

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

}

输出结果：
本应是偏向锁
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)
      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

本应是偏向锁，但是由于计算过一致性哈希，会直接升级为轻量级锁
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           28 f7 1f 9a (00101000 11110111 00011111 10011010) (-1709181144)
      4     4        (object header)                           c7 00 00 00 (11000111 00000000 00000000 00000000) (199)
      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

可以看到原先是101（偏向锁），执行了o.hashCode()后，变成了00（轻量级锁）

Code演示2

重写hashCode()方法，这个对象已经计算过identity hash code，还处于偏向锁状态

package com.bilibili.juc.syncup;

import org.openjdk.jol.info.ClassLayout;

import java.util.concurrent.TimeUnit;

public class SynchronizedUpDemo6 {

    public static void main(String[] args) {
        // 先睡眠5s，保证开启偏向锁
        try {
            TimeUnit.SECONDS.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        Book book = new Book("Java");
        System.out.println("本应是偏向锁");
        System.out.println(ClassLayout.parseInstance(book).toPrintable());

        // 重写后无效，还是偏向锁
        book.hashCode();

        synchronized (book) {
            System.out.println("本应是偏向锁，由于计算过一致性哈希，且hashCode()方法被重写了，还是偏向锁");
            System.out.println(ClassLayout.parseInstance(book).toPrintable());
        }
    }

}

class Book {

    private String name;

    public Book(String name) {
        this.name = name;
    }

    @Override
    public int hashCode() {
        return name.hashCode();
    }

}

输出结果：
本应是偏向锁
com.bilibili.juc.syncup.Book object internals:
 OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
      0     4                    (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)
      4     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4                    (object header)                           92 c3 00 f8 (10010010 11000011 00000000 11111000) (-134167662)
     12     4   java.lang.String Book.name                                 (object)
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total

本应是偏向锁，由于计算过一致性哈希，且hashCode()方法被重写了，还是偏向锁
com.bilibili.juc.syncup.Book object internals:
 OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
      0     4                    (object header)                           05 98 4e 54 (00000101 10011000 01001110 01010100) (1414436869)
      4     4                    (object header)                           5f 02 00 00 (01011111 00000010 00000000 00000000) (607)
      8     4                    (object header)                           92 c3 00 f8 (10010010 11000011 00000000 11111000) (-134167662)
     12     4   java.lang.String Book.name                                 (object)
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total

可以看到原先是101（偏向锁），执行了o.hashCode()后，但是hashCode()方法被重写了，还是101（偏向锁），因为重写了hashCode()方法后，获取的不是这个锁对象的hashcode，而是属性name的hashcode，本质上还是未计算过这个对象的identity hash code

Code演示3

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

package com.bilibili.juc.syncup;

import org.openjdk.jol.info.ClassLayout;

import java.util.concurrent.TimeUnit;

public class SynchronizedUpDemo7 {

    public static void main(String[] args) {
        // 先睡眠5s，保证开启偏向锁
        try {
            TimeUnit.SECONDS.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        Object o = new Object();
        System.out.println("本应是偏向锁");
        System.out.println(ClassLayout.parseInstance(o).toPrintable());

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

}

输出结果：
本应是偏向锁
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)
      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

偏向锁过程中遇到一致性哈希计算请求，立马撤销偏向模式，膨胀为重量级锁
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           ca 4f 5f 1c (11001010 01001111 01011111 00011100) (476008394)
      4     4        (object header)                           f4 01 00 00 (11110100 00000001 00000000 00000000) (500)
      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

可以看到原先是101（偏向锁），偏向锁过程中遇到一致性哈希计算请求，变成了10（重量级锁）

锁优缺点对比

在这里插入图片描述

synchronized锁升级和实现原理

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

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

synchronized在修饰方法和代码块在字节码上实现方式有很大差异，但是内部实现还是基于对象头的MarkWord来实现的。

JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁->偏向锁->轻量级锁->重量级锁的升级过程，而不是无论什么情况都使用重量级锁

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

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

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

JIT编译器对锁的优化

JIT

Just In Time Compiler，一般翻译为即时编译器

锁消除

Code演示

package com.bilibili.juc.syncup;

public class LockClearUpDemo {

    static Object objectLock = new Object();

    public void m1() {
        // 锁消除问题，JIT会无视它，synchronized(o)里面的锁对象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 = 0; i < 10; i++) {
            new Thread(lockClearUpDemo::m1, String.valueOf(i)).start();
        }
    }

}

输出结果：
-----------hello LockClearUpDemo	1805392722	1700522065
-----------hello LockClearUpDemo	1860423111	1700522065
-----------hello LockClearUpDemo	1244690221	1700522065
-----------hello LockClearUpDemo	2080575770	1700522065
-----------hello LockClearUpDemo	476297809	1700522065
-----------hello LockClearUpDemo	1702289086	1700522065
-----------hello LockClearUpDemo	746715365	1700522065
-----------hello LockClearUpDemo	1124920156	1700522065
-----------hello LockClearUpDemo	218295376	1700522065
-----------hello LockClearUpDemo	944921576	1700522065

说明

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

锁粗化

Code演示

package com.bilibili.juc.syncup;

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");
            }
        }, "t1").start();
    }

}

输出结果：
111111
222222
333333
444444

上面代码底层编译器会进行优化，优化后的代码时这样的：

package com.bilibili.juc.syncup;

public class LockBigDemo {

    static Object objectLock = new Object();

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

}