synchronized原理-字节码分析、对象内存结构、锁升级过程、Monitor

简介: 本文分析的问题:1. synchronized 字节码文件分析之 monitorenter、monitorexit 指令 2. 为什么任何一个Java对象都可以成为一把锁? 3. 对象的内存结构 4. 锁升级过程 (无锁、偏向锁、轻量级锁、重量级锁)5. Monitor 是什么、源码查看(hotspot虚拟机源码)6. JOL工具使用

本文分析的问题:

  1. synchronized 字节码文件分析之 monitorenter、monitorexit 指令
  2. 为什么任何一个Java对象都可以成为一把锁?
  3. 对象的内存结构
  4. 锁升级过程
  5. Monitor 是什么、源码查看

synchronized是基于monitor实现的,线程在获取锁的时候,实际上是获取了一个 monitor 对象,然后用它来进行加锁的。

字节码分析

synchronized的3种使用方式

  1. 作用于实例方法,对对象加锁
  2. 作用于静态方法,对类加锁
  3. 作用于代码块,对 () 里的对象加锁

先说结论:通过 monitorenter、monitorexit 指令来做

synchronized 关键字底层原理属于 JVM 层面的东西。

代码块

monitorenter、monitorexit 指令来做

代码:

public void m1(){
    synchronized (this){
    }
}

编译后使用 javap -v xxx.class 命令查看:

  • 一般情况下就是 1 个 monitorenter 对应 2 个 monitorexit
  • 正常处理正常释放时有一个 monitorexit,考虑到有异常时,锁应该也要被释放,所以也会有一个 monitorexit
  • 极端情况下:如果方法里抛出异常了,就只会有一个 monitorexit 指令

包含一个 monitorenter 指令以及两个 monitorexit 指令,这是为了保证锁在同步代码块正常执行以及出现异常

的这两种情况下都能被正确释放

异常情况下:只有一个 monitorexit 指令

实例方法

ACC_SYNCHRONIZED 这个标识来做

代码:

public synchronized void m1(){
}

结果:在方法下没有那两个指令,取而代之的是 ACC_SYNCHRONIZED 这个标识。该标识指明了该方法是一个同步方法

JVM通过该 ACC_SYNCHRONIZED 标识来辨别一个方法是否是一个同步方法,从而执行相应的同步调用

静态方法

ACC_SYNCHRONIZED这个标识来做

代码:

public static synchronized void m1(){
    
}

结果:可以看到还是通过 ACC_SYNCHRONIZED 这个标识来做。

ACC_STATIC 这个标识是用来区分实例方法和静态方法的,就算不加 synchronized 也会有。

对象内存结构

为了可以更加直观的看到对象结构,我们可以借助 openjdk 提供的 JOL 工具进行分析。

JOL分析工具

JOL(Java 对象布局)用于分析对象在JVM的大小和分布

官网:https://openjdk.org/projects/code-tools/jol/

<!-- 
      https://mvnrepository.com/artifact/org.openjdk.jol/jol-cli
      定位:分析对象在JVM的大小和分布 
  -->
  <dependency>
      <groupId>org.openjdk.jol</groupId>
      <artifactId>jol-cli</artifactId>
      <version>0.14</version>
  </dependency>

对象内存结构

可以看到总共分为三部分:对象头、实例数据、对齐填充

对象头

在64位系统中,Mark Word 占了 8 个字节,类型指针占了 8 个字节,一共是 16 个字节

Mark Word

MarkWord 中存了一些信息:hashCode的值、gc相关、锁相关

具体结构

  • unused:未使用的位置
  • hashcode:hashcode 的值
  • age:GC年龄(4位最大只能表示15)
  • biased_lock:是否是偏向锁(0不是;1是)
  • thread:线程id
  • epoch:偏向时间戳
  • ptr_to_lock_record:存储指向栈帧中的锁记录(LockRecord)的指针
  • ptr_to_heavyweight_monitor:指向重量级锁的指针(也就是指向 ObjectMonitor 的指针)
  • 锁标志位:01 代表有锁(通过偏向锁标志位 1/0 表示是否是偏向锁);00 代表轻量级锁;10 代表重量级锁

markOop.hpp 中的 C++ 源码查看:

//  32 bits:  32位的
//  --------
//             hash:25 ------------>| age:4    biased_lock:1 lock:2 (normal object)
//             JavaThread*:23 epoch:2 age:4    biased_lock:1 lock:2 (biased object)
//             size:32 ------------------------------------------>| (CMS free block)
//             PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object)
//
//  64 bits:  64位的
//  --------
//  unused:25 hash:31 -->| unused:1   age:4    biased_lock:1 lock:2 (normal object)
//  JavaThread*:54 epoch:2 unused:1   age:4    biased_lock:1 lock:2 (biased object)
//  PromotedObject*:61 --------------------->| promo_bits:3 ----->| (CMS promoted object)
//  size:64 ----------------------------------------------------->| (CMS free block)
//
//  unused:25 hash:31 -->| cms_free:1 age:4    biased_lock:1 lock:2 (COOPs && normal object)
//  JavaThread*:54 epoch:2 cms_free:1 age:4    biased_lock:1 lock:2 (COOPs && biased object)
//  narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->| (COOPs && CMS promoted object)
//  unused:21 size:35 -->| cms_free:1 unused:7 ------------------>| (COOPs && CMS free block)

源码地址:https://hg.openjdk.org/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.hpp

Class Pointer

对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象哪个类的实例

我们怎么知道创建的这个对象是什么类型的,就通过这个指针指向方法区的类元信息(kclass pointer)。

可能会进行指针压缩。

实例数据

存放类的属性(Field)数据信息,包括父类的属性信息

对齐填充

虚拟机要求对象起始地址必须是 8 字节的整数倍,所以填充数据不是必须存在的,仅仅是为了字节对齐,这部分内存按 8 字节补充对齐

比如:

  • 只有一个类的话,类里面是空的那就是 16 字节 = MarkWord + 类型指针(不考虑指针压缩的情况下)。这时不需要对齐填充来对齐,因为 16 字节本身就是 8 的整数倍。
  • 但假如此时有了属性,int = 4字节,boolean = 1 字节,加起来 = 16+4+1 = 21 字节,这时就不是 8 的整数 倍的,这时就需要对齐填充来补齐了
class Person {
    int age;
    boolean isFlag;
}

使用JOL工具证明

简单使用:

public static void main(String[] args) {
    // 获取JVM详细信息
    System.out.println(VM.current().details());
    // 对象头大小 开启指针压缩是12=MarkWord(8)+ClassPointer(4),没开启是16=MarkWord(8)+ClassPointer(8)
    System.out.println(VM.current().objectHeaderSize());
    // 对齐填充     为什么都是8的倍数?
    System.out.println(VM.current().objectAlignment());
}

验证对象内存结构

代码:

public static void main(String[] args) {
    Object obj = new Object();
    System.out.println(obj + " 十六进制哈希:" + Integer.toHexString(obj.hashCode()));
    System.out.println(ClassLayout.parseInstance(obj).toPrintable());
}

结果:

  • Object对象,总共占16字节
  • 对象头占 12 个字节,其中:mark-word 占 8 字节、Klass Point 占 4 字节
  • 最后 4 字节,用于数据填充对齐
指针压缩

不是说类型指针是8字节吗,到这里怎么变为4字节了?

那是因为被 指针压缩 了(开启后性能会更好)

命令查看: java -XX:+PrintCommandLineFlags -version

这个参数就是压缩指针的参数:-XX:+UseCompressedClassPointers +代表开启,- 代表关闭

关闭后,运行后,再次查看:-XX:-UseCompressedClassPointers

这次就没有对齐填充了。

锁升级过程

无锁 ---> 偏向锁 ---> 轻量级锁   -> 重量级锁

出现的背景

之前 synchronized 是重量级锁,依靠 Monitor 机制实现。

Monitor 是依赖于底层的操作系统的 Mutex Lock(互斥锁)来实现的线程同步。这种机制需要用户态和内核态之

间来切换。但Mutex是系统方法,由于权限的关系,应用程序调用系统方法时需要切换到内核态来执行。

所以为了是减少用户态和内核态之间的切换。因为这两种状态之间的切换的开销比较高。

先来一个 狗 的类,用来创建对象

class Dog {
}

无锁

创建一个对象,没有一个线程来占有它,这时就是无锁

无锁时 Mark Word 的结构:

| unused:25 | hashcode:31 | unused:1 | age:4 | biased_lock:0 | 01    |       Normal       |

测试代码:

public static void main(String[] args) {
    Dog dog = new Dog();
    dog.hashCode();
    System.out.println(ClassLayout.parseInstance(dog).toPrintable());
    System.out.println("======================================================");
    System.out.println(dog);
    System.out.println("十六进制:" + Integer.toHexString(dog.hashCode()));
    System.out.println("二进制:" + Integer.toBinaryString(dog.hashCode()));
}

对照上面的结构来看:从后往前按照 Mark Word 结构来看。每8bit从前往后看。

偏向锁

当第一个线程来获取到它时(没有竞争/一次就竞争成功),这时它就是偏向锁,只偏向于这一个线程(CAS)

偏向锁、轻量级锁的 Mark Word 的结构:

|--------------------------------------------------------------------|--------------------|
| thread:54 | epoch:2     | unused:1 | age:4 | biased_lock:1 | 01    |      Biased        |  
|--------------------------------------------------------------------|--------------------|
|             ptr_to_lock_record:62                          | 00    | Lightweight Locked |
|--------------------------------------------------------------------|--------------------|

测试代码:

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

结果:

这里的锁为什么直接是轻量级锁呢?

因为偏向锁默认是延迟开启的,所以进入了轻量级锁状态。

使用 java -XX:+PrintFlagsInitial | grep BiasedLock 命令在 Git Bash 下执行:

所以需要添加参数 -XX:BiasedLockingStartupDelay=0,让其在程序启动时立刻启动。或者让程序睡了 5 秒后再执行。

添加参数/睡5秒后执行,发现偏向锁出现了:

1 代表是偏向锁,01 代表有锁

轻量级锁

其实就是自旋锁(底层是CAS)

其它线程来竞争锁,并且竞争失败,会到一个全局安全点来把这个锁升级为轻量级锁

轻量级锁的 Mark Word 结构:

|             ptr_to_lock_record:62                          | 00    | Lightweight Locked |

测试代码:通过调用 hashCode() 来得到轻量级锁(因为偏向锁里没有地方存储 hashCode 的值)

public static void main(String[] args) throws InterruptedException {
    Dog dog = new Dog();
    dog.hashCode();
    synchronized (dog) {
        System.out.println(ClassLayout.parseInstance(dog).toPrintable());
    }
}

结果:

自旋次数

JDK6之前

  • 默认启用,默认情况下自旋的次数是10次,或者自旋线程数超过CPU核数一半

JDK6之后 自适应自旋锁

  • 线程如果自旋成功了,那下次自旋的最大次数会增加,因为JVM认为既然上次成功了,那么这一次也很大概率会成功。
  • 反之,如果很少会自旋成功,那么下次会减少自旋的次数其至不自旋,避免CPU空转。
  • 自适应意味着自旋的次数不是固定不变的,而是根据:同一个锁上一次自旋的时间。拥有锁线程的状态来决定。

重量级锁

自旋到一定次数后,还没获取到锁,会将其升级为重量级锁。那就是阻塞了,用户态和内核态之间的切换

基于 Monitor 的实现,monitorenter 和 monitorexit 指令来实现

重量级锁的 Mark Word 的结构:

|           ptr_to_heavyweight_monitor:62                    | 10    | Heavyweight Locked |

测试代码:

public static void main(String[] args) throws InterruptedException {
    Dog dog = new Dog();

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

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

结果:

锁升级后,hash值去哪?

  • 无锁:就存在 Mark Word 里
  • 偏向锁:没有地方存 hash 值了
  • 如果在 synchronized 前调用了 hashCOde() ,此时偏向锁会升级为轻量级锁
  • 如果在 synchronized 中调用了 hashCode() ,此时偏向锁会升级为重量级锁
  • 轻量级锁:栈帧中的锁记录(Lock Record)里
  • 重量级锁:Mark Word 保存重量级锁的指针,底层实现 ObjectMonitor 类里有字段记录加锁状态的 Mark Word 信息

必须说的 monitor

在 HotSpot 虚拟机中,monitor 是由 C++ 中的 ObjectMonitor 实现。

什么是 Monitor

Monitor 是管程,是同步监视器,是一种同步机制。为了保证数据的安全性

Monitor 有什么用

提供了一种互斥机制。限制同一时刻只能有一个线程进入 Monitor 的临界区,保护数据安全。

用于保护共享数据,避免多线程并发访问导致数据不一致。

synchronized 的重量级锁就是用 Monitor 来实现的

Monitor 的源码分析

线程在获取锁的时候,实际上是获取了一个 monitor 对象

每个 Java 对象都自带了一个 monitor 对象,所以每个 Java 对象都可以成为锁。

源码:Java 中的每个对象都继承自 Object 类,而每个 Java 对象在 JVM 内部都有一个 C++ 对象 oopDesc 与其对应,而对应的 oopDesc 内有一个属性是 markOopDesc 对象(这个对象就是 Java 里的 Mark Word),这个 markOopDesc 内有一个 monitor() 方法返回了 ObjectMonitor 对象(hotspot中,这个对象实现了 monitor )

oopDesc

这个类是每个 Java 对象的基类。每个 Java 对象在虚拟机内部都会继承这个 C++ 对象。

源码地址:https://hg.openjdk.org/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/oops/oop.hpp

markOopDesc

这个类也是 oopDesc 的子类。这个类就是 Mark Word 对象头。

里面有一个 monitor() 方法返回了 ObjectMonitor 对象。

monitor():

源码地址:https://hg.openjdk.org/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/oops/markOop.hpp

ObjectMonitor

在 hotspot 虚拟机中,ObjectMonitor 是 Monitor 的实现。

源码地址:https://hg.openjdk.org/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.hpp

为什么任何一个Java对象都可以成为一把锁

synchronized是基于monitor实现的,线程在获取锁的时候,实际上是获取了一个 monitor 对象。而Java 中的每个对象都继承自 Object 类,虚拟机源码中 oopDesc 是每个 Java 对象的顶层父类,这个父类内有个属性是 markOopDesc 对象,也就是对象头。这个对象头是存储锁的地方,里面有一个 ObjectMonitor 。而 monitor 的实现就是 ObjectMonitor 对象监视器。

每一个被锁住的对象又都会和 Monitor 关联起来,通过对象头里的指针。

参考资料

大部分参考:

  1. https://www.bilibili.com/video/BV1ar4y1x727/

Mark Word 代码块里的结构参考视频的笔记(图为自画):

  1. https://www.bilibili.com/video/BV16J411h7Rd

少部分参考:

  1. https://www.cnblogs.com/wuzhenzhao/p/10250801.html
  2. https://segmentfault.com/a/1190000037645482
  3. https://www.cnblogs.com/mic112/p/16388456.html

oopDesc、markOopDesc 和 Java 对象之间的关系参考:

  1. https://www.cnblogs.com/mazhimazhi/p/13289686.html
  2. https://blog.csdn.net/qq_31865983/article/details/99173570

为什么每一个Java对象都可以成为一把锁?

openjdk 源码位置参考:里面也有 ObjectMonitor 原理

  1. https://www.cnblogs.com/webor2006/p/11442551.html
相关文章
|
8天前
|
缓存 关系型数据库 MySQL
MySQL数据库——InnoDB引擎-架构-内存结构(Buffer Pool、Change Buffer、Adaptive Hash Index、Log Buffer)
MySQL数据库——InnoDB引擎-架构-内存结构(Buffer Pool、Change Buffer、Adaptive Hash Index、Log Buffer)
24 3
|
9天前
|
存储 Java 编译器
jvm内存结构
jvm内存结构
21 0
|
9天前
|
存储 Java
JVM内存结构(4)
JVM内存结构
12 1
|
9天前
|
存储 Java 编译器
JVM内存结构(3)
JVM内存结构
10 0
|
9天前
|
存储 数据可视化 Java
|
9天前
|
存储 安全 Java
|
16天前
|
程序员 内存技术
深入理解操作系统内存管理:原理与实践
【5月更文挑战第30天】 在现代计算机系统中,操作系统的内存管理是确保系统高效、稳定运行的关键。本文将深入探讨操作系统中内存管理的理论基础和实际应用,包括物理内存与虚拟内存的映射机制、分页与分段技术、以及内存分配策略等。通过对内存管理机制的分析与案例实践,旨在为读者提供一个清晰的内存管理概念框架和操作指南,帮助理解操作系统如何优化内存资源使用,提高系统性能。
|
16天前
|
存储 Linux 开发者
深入理解操作系统内存管理:原理与实践
【5月更文挑战第30天】 本文旨在探讨操作系统中的内存管理机制,其核心是内存的有效分配、使用与回收。我们将从内存管理的基本原理出发,逐步深入到具体的实现技术,如分页、分段和虚拟内存等。文章将详细阐述每种技术的工作原理、优势及其可能面临的问题,并通过实际案例来展示这些技术在现代操作系统中的应用。通过阅读本文,读者将对操作系统的内存管理有一个全面而深入的了解,并能够对常见的内存问题进行诊断和优化。
|
16天前
|
缓存 算法 Java
深入理解操作系统内存管理:原理与实践
【5月更文挑战第30天】 操作系统的心脏——内存管理,是确保系统高效稳定运行的关键。本文将深入剖析操作系统内存管理的基本原理,包括物理内存与虚拟内存的映射机制、分页与分段技术、以及内存分配策略等。同时,结合现代操作系统实例,探讨内存管理在多任务环境中的创新应用,如Linux内核的内存管理优化。文章旨在为读者提供一个全面、深入的视角,以理解并掌握操作系统中这一至关重要的组成部分。
|
16天前
|
存储 缓存 算法
深入理解操作系统的内存管理:原理与实践
【5月更文挑战第30天】 在现代计算机系统中,操作系统扮演着至关重要的角色,尤其是内存管理作为其核心功能之一。本文将详细探讨操作系统内存管理的基本原理、关键技术以及实际应用场景。我们将从内存层次结构出发,解析地址转换和分页机制,并探讨虚拟内存技术如何使得系统运行更加高效稳定。同时,通过分析具体案例,本文还将展示内存管理在提升系统性能和安全性方面的重要作用。

相关实验场景

更多