详解JVM系列之对象的锁状态和同步

java对象头

Java的锁状态其实可以分为三种,分别是偏向锁,轻量级锁和重量级锁。

在Java HotSpot VM中,每个对象前面都有一个class指针和一个Mark Word。 Mark Word存储了哈希值以及分代年龄和标记位等,通过这些值的变化,JVM可以实现对java对象的不同程度的锁定。

还记得我们之前分享java对象的那张图吗?

javaObject对象的对象头大小根据你使用的是32位还是64位的虚拟机的不同,稍有变化。这里我们使用的是64位的虚拟机为例。

Object的对象头,分为两部分,第一部分是Mark Word,用来存储对象的运行时数据比如:hashcode,GC分代年龄,锁状态,持有锁信息,偏向锁的thread ID等等。

在64位的虚拟机中,Mark Word是64bits,如果是在32位的虚拟机中Mark Word是32bits。

第二部分就是Klass Word,Klass Word是一个类型指针,指向class的元数据,JVM通过Klass Word来判断该对象是哪个class的实例。

我们可以看到对象头中的Mark Word根据状态的不同,存储的是不同的内容。

其中锁标记的值分别是:无锁=001,偏向锁=101,轻量级锁=000,重量级锁=010。

java中锁状态的变化

为什么java中的锁有三种状态呢?其本质原因是为了提升锁的效率,因为不同情况下,锁的力度是不一样的。

通过设置不同的锁的状态,从而可以不同的情况用不同的处理方式。

下图是java中的锁状态的变化图:

上面的图基本上列出了java中锁状态的整个生命周期。接下来我们一个一个的讲解。

偏向锁biased locking

一般来说,一个对象被一个线程获得锁之后,很少发生线程切换的情况。也就是说大部分情况下,一个对象只是被一个对象锁定的。

那么这个时候我们可以通过设置Mark word的一定结构,减少使用CAS来更新对象头的频率。

为了实现这样的目标,我们看下偏向锁的Mark word的结构:

当偏向线程第一次进入同步块的时候,会去判断偏向锁的状态和thread ID,如果偏向锁状态是1,并且thread ID是空的话,将会使用CAS命令来更新对象的Mark word。

设置是否偏向锁=1,锁标记=01,线程ID设置为当前锁定该对象的线程。

下一次该对象进入同步块的时候,会先去判断锁定的线程ID和当前线程ID是否相等,如果相等的话则不需要执行CAS命令,直接进入同步块。

如果这个时候有第二个线程想访问该对象的同步块,因为当前对象头的thread ID是第一个线程的ID,跟第二个线程的ID不同。

如果这个时候线程1的同步块已经执行完毕,那么需要解除偏向锁的锁定。

解除锁定很简单,就是将线程ID设置为空,并且将偏向锁的标志位设为0,

如果这个时候线程1的同步块还在执行,那么需要将偏向锁升级为轻量级锁。

轻量级锁thin lock

先看下轻量级锁的结构:

可以看到Mark word中存放的是栈中锁记录的指针和锁的标记=00。

如果对象现在处于未加锁状态,当一个线程尝试进入同步块的时候,会将把对象头和当前对象的指针拷贝一份,放在线程的栈中一个叫做lock record的地方。

然后JVM通过CAS操作,将对象头中的指针指向刚刚拷贝的lock record。如果成功,则该线程拥有该对象的锁。

实际上Lock Record和Mark word形成了一个互相指向对方的情况。

下次这个线程再次进入同步块的时候,同样执行CAS,比较Mark word中的指针是否和当前thread的lock record地址一致,如果一致表明是同一个线程,可以继续持有该锁。

如果这个时候有第二个线程,也想进入该对象的同步块,也会执行CAS操作,很明显会失败,因为对象头中的指针和lock record的地址不一样。

这个时候第二个线程就会自旋等待。

那么第一个线程什么时候会释放锁呢?

轻量级锁在线程退出同步块的时候,同样需要执行CAS命令,将锁标记从00替换成01,也就是无锁状态。

重量级锁

如果第二个线程自旋时间太久,就会将锁标记替换成10(重量级锁),并且设置重量级锁的指针,指向第二个线程,然后进入阻塞状态。

当第一个线程退出同步块的时候,执行CAS命令就会出错,这时候第一个线程就知道锁已经膨胀成为重量级锁了。

第一个线程就会释放锁,并且唤醒等待的第二个线程。

第二个线程被唤醒之后,重新争夺锁。

我们看下重量级锁的结构:

三种锁状态的不同

偏向锁,轻量级锁和重量级锁到底有什么不同了?

这里总结一下,偏向锁下次进入的时候不需要执行CAS命令,只做线程ID的比较即可。

轻量级锁进入和退出同步块都需要执行CAS命令,但是轻量级锁不会阻塞,它使用的是自旋命令来获取锁。

重量级锁不使用自旋,但是会阻塞线程。!

以上就是详解JVM系列之对象的锁状态和同步的详细内容,更多关于JVM系列之对象的锁状态和同步的资料请关注我们其它相关文章!

(0)

相关推荐

  • 详解JVM 中的StringTable

    是什么 字符串常量池是 JVM中的一个重要结构,用于存储JVM运行时产生的字符串.在JDK7之前在方法区中,存储的是字符串常量.而字符串常量池在 JDK7开始移入堆中,随之而来的是除了存储字符串常量外,还可以存储字符串引用(因为在堆中,引用堆中的字符串常量很方便,所以可以存储引用).这使得很多字符串的操作在 JDK7中和在之前的版本中执行是不同的结果.这也是为什么字符串相关的问题是如此具有迷惑性的原因之一. 底层 String:在 JDK9之前,String底层是使用 char数组来存储字符串数

  • JVM常量池的深入讲解

    提示:这里咱们要说的常量池,常量池就是咱们面试中所说的常量池,谈谈你对常量池的认识?面试官一问咱们就懵逼了,你要记得你脑子中有一张图!!! 剩下的就好办了 提示:请各位大佬批评指正!! 前言 提示:学习的时候会有点头疼哦 一.Class常量池与运行时常量池 Class常量池可以理解为是Class文件中的资源仓库. Class文件中除了包含类的版本.字段.方法.接口等描述信息外,还有一项信息就是 常量池(constant pool table) ,用于存放编译期生成的各种 字面量(Literal)

  • java虚拟机之JVM调优详解

    JVM常用命令行参数 1. 查看参数列表 虚拟机参数分为基本和扩展两类,在命令行中输入 JAVA_HOME\bin\java就可得到基本参数列表. 在命令行输入 JAVA_HOME\bin\java –X就可得到扩展参数列表. 2. 基本参数说明: -client,-server: 两种Java虚拟机启动方式,client模式启动比较快,但是性能和内存管理相对较差,server模式启动比较慢,但是运行性能比较高,windos上采用的是client模式,Linux采用server模式 -class

  • jvm运行原理以及类加载器实例详解

    JVM运行原理 首先从".java"代码文件,编译成".class"字节码文件,然后类加载器将".class"字节码文件中的类给加载带JVM中,最后就是JVM执行写好的代码.执行过程如下图 类加载器 类加载过程 加载 -> 验证 -> 准备 -> 解析 -> 初始化 -> 使用 -> 卸载 加载 一旦JVM进程启动之后,一定会先把类加载到内存中,然后从main()方法的入口代码开始执行 public class

  • 华为技术专家讲解JVM内存模型(收藏)

    全是干货的技术号: 本文已收录在[github面试知识仓库],欢迎 star/fork: https://github.com/Wasabi1234/Java-Interview-Tutorial 内存是非常重要的系统资源,是硬盘和CPU的中间仓库及桥梁,承载着操作系统和应用程序的实时运行. JVM内存布局规定了Java在运行过程中内存申请.分配.管理的策略,保证了JVM的高效稳定运行.不同的JVM对于内存的划分方式和管理机制存在着部分差异.结合JVM虚拟机规范,来探讨经典的JVM内存布局. J

  • Java 汇编JVM编写jasmin程序的操作方法

    Jasmin是Java汇编语言,以文本方式来描述JVM的指令集以及Java Class的结构,Jasmin编译器可以把汇编语言转换成二进制的字节码,使JVM可以调入执行. Jasmin最初是由Jon Meyer和Troy Downing编纂<Java Virtual Machine>时设计的范例,虽然该书不再出版,但是Jasmin成为了事实上的Java汇编语言标准,并作为开源项目得到发展:http://jasmin.sourceforge.net/. Jasmin在Java class方面的处

  • elasticsearch启动警告无法锁定JVM内存

    elasticsearch启动警告 Unable to lock JVM memory (ENOMEM). This can result in part of the JVM being swapped out. Increase RLIMIT_MEMLOCK (ulimit). 内存锁定值的限制(max locked memory) 这个值只对普通用户起作用,对超级用户不起作用,这个问题是由于CAP_IPC_LOCK造成的.linux对内存是分页管理的,这意味着有不需要时,在物理内存的数据会

  • 浅谈Java堆外内存之突破JVM枷锁

    对于有Java开发经验的朋友都知道,Java中不需要手动的申请和释放内存,JVM会自动进行垃圾回收:而使用的内存是由JVM控制的. 那么,什么时机会进行垃圾回收,如何避免过度频繁的垃圾回收?如果JVM给的内存不够用,怎么办? 此时,堆外内存登场!利用堆外内存,不仅可以随意操控内存,还能提高网络交互的速度. 背景1:JVM内存的分配 对于JVM的内存规则,应该是老生常谈的东西了,这里我就简单的说下: 新生代:一般来说新创建的对象都分配在这里. 年老代:经过几次垃圾回收,新生代的对象就会放在年老代里

  • 详解jvm对象的创建和分配

    对象的创建 创建方式 1. new 关键字直接创建. new ObjectName(). 2.通过 Class 反射对象的 newInstance() 方法.ObjectName  obj  =  ObjectName.class.newInstance(). 3.通过 Class 反射对象获取 Constructor 类,再调用其 newInstance() 方法. ObjectName obj = ObjectName.class.getConstructor.newInstance().

  • JVM---jstack分析Java线程CPU占用,线程死锁的解决

    本文章主要演示在Windows环境,Linux环境也差不多. 一.分析CPU占用飙高 首先写一个Java程序,并模拟一个死循环.让CPU使用率飙高.CPU负载过大的话,新的请求就处理不了了,这就是很多程序变慢了甚至不能访问的原因之一. 下面是我这里的Controller,启动程序之后,开多个请求访问这个方法.死循环代码就不贴了,自己构造.我这里模拟的一个截取字符串的死循环. /** * 演示死循环导致cpu使用率飙高 * */ @RequestMapping("/loop") publ

随机推荐