纯净、安全、绿色的下载网站

首页|软件分类|下载排行|最新软件|IT学院

当前位置:首页IT学院IT技术

java synchronized锁升级 java中synchronized锁的升级过程

NetWhite   2021-09-13 我要评论
想了解java中synchronized锁的升级过程的相关内容吗NetWhite在本文为您仔细讲解java synchronized锁升级的相关知识和一些Code实例欢迎阅读和指正我们先划重点:java,锁升级,synchronized锁的升级,java锁升级过程下面大家一起来学习吧

synchronized锁的升级(偏向锁、轻量级锁及重量级锁)

java同步锁前置知识点

  • 1.编码中如果使用锁可以使用synchronized关键字对方法、代码块进行同步加锁
  • 2.Synchronized同步锁是jvm内置的隐式锁(相对Lock隐式加锁与释放)
  • 3.Synchronized同步锁的实现依赖于操作系统获取锁与释放锁进行系统调用会引起用户态与内核态切换
  • 4.jdk1.5之前加锁只能使用synchronized1.6引入Lock同步锁(请求锁基于java实现显式加锁与释放、性能更优)
  • 5.jdk1.6对于Synchronzied同步锁提出了偏向锁、轻量级锁、重量级锁的概念(其实是对synchronized的性能优化尽可能减少锁竞争带来的上下文切换)
  • 6.无论是使用synchronized还是Lock线程上下文切换都是无法避免的
  • 7.Lock相对synchronized的性能优化的其中一点是:在线程阻塞的时候Lock获取锁不会导致用户态与内核态的切换而synchronized会(看第3点)但是线程阻塞都会导致上下文切换(看第6点)
  • 8.java线程的阻塞与唤醒依赖操作系统调用导致用户态与内核态切换
  • 9.前面说的用户态与内核态切换发生的是进程上下文切换而非线程上下文切换

本文主要关注synchronized锁的升级

synchronized同步锁

java对象头

每个java对象都有一个对象头对象头由类型指针和标记字段组成

在64位虚拟机中未开启压缩指针标记字段占64位类型指针占64位共计16个字节

锁类型信息为标记字段的最后2位:00表示轻量级锁01表示无锁或偏向锁10表示重量级锁;如果倒数第3位为1表示这个类的偏向锁启用为0表示类的偏向锁被禁用

如下图图片来源wiki

左侧一列表示偏向锁启用(方框1)右侧一列表示偏向锁禁用(方框3)1和3都表示无锁的初始状态如果启用偏向锁锁升级的步骤应该是1->2->4->5如果禁用偏向锁锁升级步骤是3->4->5

我用的jdk8打印了参数看了下默认是启用偏向锁如要是禁用: -XX:-UseBiasedLocking

关于偏向锁还有另外几个参数:

注意BiasedLockingStartupDelay参数默认值4000ms表示虚拟机启动的延迟4s才会使用偏向锁(先使用轻量级锁)

偏向锁

偏向锁处理的场景是大部分时间只有同一条线程在请求锁没有多线程竞争锁的情况看对象头图的红框2有个thread ID字段:当第一次线程加锁的时候jvm通过cas将当前线程地址设置到thread ID标记位最后3位是101下次同一线程再获取锁的时候只用检查最后3位是否为101是否为当前线程epoch是否和锁对象的类的epoch相等(wiki上说没有再次cas设置是为了针对现在多处理器上的cas操作的优化)

偏向锁优化带来的性能提升指的是避免了获取锁进行系统调用导致的用户态和内核态的切换因为都是同一条线程获取锁没有必要每次获取锁的时候都要进行系统调用

如果当前线程获取锁的时候(无锁状态下)线程ID与当前线程不匹配会将偏向锁撤销重新偏向当前线程如果次数达到BiasedLockingBulkRebiasThreshold的值默认20次当前类的偏向锁失效影响就是epoch的值变动加锁类的epoch值加1后续锁对象会重新copy类的epoch值到图中的epoch标记位如果总撤销次数达到BiasedLockingBulkRevokeThreshold的值(默认40次)就禁用当前类的偏向锁了就是对象头右侧列了加锁直接从轻量锁开始了(锁升级了)

偏向锁的撤销是个很麻烦的过程需要所有线程达到安全点(发生STW)遍历所有线程的线程栈检查是否持有锁对象避免丢锁还有就是对epoch的处理

如果存在多线程竞争那偏向锁就要升级了升级到轻量级锁

轻量级锁

轻量级锁处理的场景是在同的时间段有不同的线程请求锁(线程交替执行)即使同一时间段存在多条线程竞争锁获取到锁的线程持有锁的时间也特别短很快就释放锁了

线程加锁的时候判断不是重量级锁就会在当前线程栈内开辟一个空间作为锁记录将锁对象头的标记字段复制过来(复制过来是做一个记录因为后面要把锁对象头的标记字段的值替换为刚才复制这个标记字段的空间地址就像对象头那个图片中的pointer to lock record部分至于最后2位因为是内存对齐的缘故所以是00)然后基于CAS操作将复制这个标记字段的地址设置为锁对象头的标记位的值如果成功就是获取到锁了如果加锁的时候判断不是重量级锁最后两位也不是01(从偏向锁或无锁状态过来的)那就说明已经有线程持有了如果是当前线程在(需要重入)那就设置一个0这里是个栈结构直接压入一个0即可最后释放锁的时候出栈最后一个元素记录的就是锁对象原来的标记字段的值再通过CAS设置到锁对象头即可

注意在获取锁的时候cas失败当前线程会自旋一会达到一定次数升级到重量级锁当前线程也会阻塞

重量级锁

重量级就是我们平常说的加的同步锁也就是java基础的锁实现获取锁与释放锁的时候都要进行系统调用从而导致上下文切换

关于自旋锁

关于自旋锁我查阅相关资料主要有两种说明:

1、是轻量级锁竞争失败不会立即膨胀为重量级而是先自旋一定次数尝试获取锁;

2、是重量级锁竞争失败也不会立即阻塞也是自旋一定次数(这里涉及到一个自调整算法)

关于这个说明还是要看jvm的源码实现才能确定哪个是真实的:

打印偏向锁的参数

如下:

-XX:+UnlockDiagnosticVMOptions

-XX:+PrintBiasedLockingStatistics

我在main方法循环获取同一把锁打印结果如下:

    public static void main(String[] args) {
        int num = 0;
        for (int i = 0; i < 1_000_000000; i++) {
            synchronized (lock) {
                num++;
            }
        }
    }

synchronized原理解析

一:synchronized原理解析

1:对象头

首先我们要知道对象在内存中的布局:

已知对象是存放在堆内存中的对象大致可以分为三个部分分别是对象头、实例变量和填充字节

  • 对象头zhuyao是由MarkWord和Klass Point(类型指针)组成其中Klass Point是对象指向它的类元数据的指针虚拟机通过这个指针来确定这个对象是哪个类的实例Mark Word用于存储对象自身的运行时数据如果对象是数组对象那么对象头占用3个字宽(Word)如果对象是非数组对象那么对象头占用2个字宽(1word = 2 Byte = 16 bit)
  • 实例变量存储的是对象的属性信息包括父类的属性信息按照4字节对齐
  • 填充字符因为虚拟机要求对象字节必须是8字节的整数倍填充字符就是用于凑齐这个整数倍的

对象头示例

通过第一部分可以知道Synchronized不论是修饰方法还是代码块都是通过持有修饰对象的锁来实现同步那么Synchronized锁对象是存在哪里的呢?答案是存在锁对象的对象头的MarkWord中那么MarkWord在对象头中到底长什么样也就是它到底存储了什么呢?

在32位的虚拟机中:

在64位的虚拟机中:

上图中的偏向锁和轻量级锁都是在java6以后对锁机制进行优化时引进的下文的锁升级部分会具体讲解Synchronized关键字对应的是重量级锁接下来对重量级锁在Hotspot JVM中的实现锁讲解

2:Synchronized在JVM中的实现原理

重量级锁对应的锁标志位是10存储了指向重量级监视器锁的指针在Hotspot中对象的监视器(monitor)锁对象由ObjectMonitor对象实现(C++)其跟同步相关的数据结构如下:

ObjectMonitor() {
    _count        = 0; //用来记录该对象被线程获取锁的次数
    _waiters      = 0;
    _recursions   = 0; //锁的重入次数
    _owner        = NULL; //指向持有ObjectMonitor对象的线程 
    _WaitSet      = NULL; //处于wait状态的线程会被加入到_WaitSet
    _WaitSetLock  = 0 ;
    _EntryList    = NULL ; //处于等待锁block状态的线程会被加入到该列表
  }

光看这些数据结构对监视器锁的工作机制还是一头雾水那么我们首先看一下线程在获取锁的几个状态的转换:

线程的生命周期存在5个状态start、running、waiting、blocking和dead

对于一个synchronized修饰的方法(代码块)来说:

  • 当多个线程同时访问该方法那么这些线程会先被放进_EntryList队列此时线程处于blocking状态
  • 当一个线程获取到了实例对象的监视器(monitor)锁那么就可以进入running状态执行方法此时ObjectMonitor对象的_owner指向当前线程_count加1表示当前对象锁被一个线程获取
  • 当running状态的线程调用wait()方法那么当前线程释放monitor对象进入waiting状态ObjectMonitor对象的_owner变为null_count减1同时线程进入_WaitSet队列直到有线程调用notify()方法唤醒该线程则该线程重新获取monitor对象进入_Owner区
  • 如果当前线程执行完毕那么也释放monitor对象进入waiting状态ObjectMonitor对象的_owner变为null_count减1

那么Synchronized修饰的代码块/方法如何获取monitor对象的呢?

在JVM规范里可以看到不管是方法同步还是代码块同步都是基于进入和退出monitor对象来实现然而二者在具体实现上又存在很大的区别通过javap对class字节码文件反编译可以得到反编译后的代码

(1)Synchronized修饰代码块:

Synchronized代码块同步在需要同步的代码块开始的位置插入monitorentry指令在同步结束的位置或者异常出现的位置插入monitorexit指令;JVM要保证monitorentry和monitorexit都是成对出现的任何对象都有一个monitor与之对应当这个对象的monitor被持有以后它将处于锁定状态

例如同步代码块如下:

public class SyncCodeBlock {
   public int i;
   public void syncTask(){
       synchronized (this){
           i++;
       }
   }
}

对同步代码块编译后的class字节码文件反编译结果如下(仅保留方法部分的反编译内容):

  public void syncTask();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=3, args_size=1
         0: aload_0
         1: dup
         2: astore_1
         3: monitorenter  //注意此处进入同步方法
         4: aload_0
         5: dup
         6: getfield      #2             // Field i:I
         9: iconst_1
        10: iadd
        11: putfield      #2            // Field i:I
        14: aload_1
        15: monitorexit   //注意此处退出同步方法
        16: goto          24
        19: astore_2
        20: aload_1
        21: monitorexit //注意此处退出同步方法
        22: aload_2
        23: athrow
        24: return
      Exception table:
      //省略其他字节码.......

可以看出同步方法块在进入代码块时插入了monitorentry语句在退出代码块时插入了monitorexit语句为了保证不论是正常执行完毕(第15行)还是异常跳出代码块(第21行)都能执行monitorexit语句因此会出现两句monitorexit语句

(2)Synchronized修饰方法:

Synchronized方法同步不再是通过插入monitorentry和monitorexit指令实现而是由方法调用指令来读取运行时常量池中的ACC_SYNCHRONIZED标志隐式实现的如果方法表结构(method_info Structure)中的ACC_SYNCHRONIZED标志被设置那么线程在执行方法前会先去获取对象的monitor对象如果获取成功则执行方法代码执行完毕后释放monitor对象如果monitor对象已经被其它线程获取那么当前线程被阻塞

同步方法代码如下:

public class SyncMethod {
   public int i;
   public synchronized void syncTask(){
           i++;
   }
}

对同步方法编译后的class字节码反编译结果如下(仅保留方法部分的反编译内容):

public synchronized void syncTask();
    descriptor: ()V
    //方法标识ACC_PUBLIC代表public修饰ACC_SYNCHRONIZED指明该方法为同步方法
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=3, locals=1, args_size=1
         0: aload_0
         1: dup
         2: getfield      #2                  // Field i:I
         5: iconst_1
         6: iadd
         7: putfield      #2                  // Field i:I
        10: return
      LineNumberTable:
        line 12: 0
        line 13: 10
}

可以看出方法开始和结束的地方都没有出现monitorentry和monitorexit指令但是出现的ACC_SYNCHRONIZED标志位

三、锁的优化

1、锁升级

锁的4中状态:无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态(级别从低到高)

(1)偏向锁:

为什么要引入偏向锁?

  • 因为经过HotSpot的作者大量的研究发现大多数时候是不存在锁竞争的常常是一个线程多次获得同一个锁因此如果每次都要竞争锁会增大很多没有必要付出的代价为了降低获取锁的代价才引入的偏向锁

偏向锁的升级:

  • 当线程1访问代码块并获取锁对象时会在java对象头和栈帧中记录偏向的锁的threadID因为偏向锁不会主动释放锁因此以后线程1再次获取锁的时候需要比较当前线程的threadID和Java对象头中的threadID是否一致如果一致(还是线程1获取锁对象)则无需使用CAS来加锁、解锁;如果不一致(其他线程如线程2要竞争锁对象而偏向锁不会主动释放因此还是存储的线程1的threadID)那么需要查看Java对象头中记录的线程1是否存活如果没有存活那么锁对象被重置为无锁状态其它线程(线程2)可以竞争将其设置为偏向锁;如果存活那么立刻查找该线程(线程1)的栈帧信息如果还是需要继续持有这个锁对象那么暂停当前线程1撤销偏向锁升级为轻量级锁如果线程1 不再使用该锁对象那么将锁对象状态设为无锁状态重新偏向新的线程

偏向锁的取消:

  • 偏向锁是默认开启的而且开始时间一般是比应用程序启动慢几秒如果不想有这个延迟那么可以使用-XX:BiasedLockingStartUpDelay=0;
  • 如果不想要偏向锁那么可以通过-XX:-UseBiasedLocking = false来设置;

(2)轻量级锁

为什么要引入轻量级锁?

  • 轻量级锁考虑的是竞争锁对象的线程不多而且线程持有锁的时间也不长的情景因为阻塞线程需要CPU从用户态转到内核态代价较大如果刚刚阻塞不久这个锁就被释放了那这个代价就有点得不偿失了因此这个时候就干脆不阻塞这个线程让它自旋这等待锁释放

轻量级锁什么时候升级为重量级锁?

  • 线程1获取轻量级锁时会先把锁对象的对象头MarkWord复制一份到线程1的栈帧中创建的用于存储锁记录的空间(称为DisplacedMarkWord)然后使用CAS把对象头中的内容替换为线程1存储的锁记录(DisplacedMarkWord)的地址;
  • 如果在线程1复制对象头的同时(在线程1CAS之前)线程2也准备获取锁复制了对象头到线程2的锁记录空间中但是在线程2CAS的时候发现线程1已经把对象头换了线程2的CAS失败那么线程2就尝试使用自旋锁来等待线程1释放锁
  • 但是如果自旋的时间太长也不行因为自旋是要消耗CPU的因此自旋的次数是有限制的比如10次或者100次如果自旋次数到了线程1还没有释放锁或者线程1还在执行线程2还在自旋等待这时又有一个线程3过来竞争这个锁对象那么这个时候轻量级锁就会膨胀为重量级锁重量级锁把除了拥有锁的线程都阻塞防止CPU空转

注意:为了避免无用的自旋轻量级锁一旦膨胀为重量级锁就不会再降级为轻量级锁了;偏向锁升级为轻量级锁也不能再降级为偏向锁一句话就是锁可以升级不可以降级但是偏向锁状态可以被重置为无锁状态

(3)这几种锁的优缺点(偏向锁、轻量级锁、重量级锁)

2、锁粗化

  • 按理来说同步块的作用范围应该尽可能小仅在共享数据的实际作用域中才进行同步这样做的目的是为了使需要同步的操作数量尽可能缩小缩短阻塞时间如果存在锁竞争那么等待锁的线程也能尽快拿到锁
  • 但是加锁解锁也需要消耗资源如果存在一系列的连续加锁解锁操作可能会导致不必要的性能损耗
  • 锁粗化就是将多个连续的加锁、解锁操作连接在一起扩展成一个范围更大的锁避免频繁的加锁解锁操作

3、锁消除

  • Java虚拟机在JIT编译时(可以简单理解为当某段代码即将第一次被执行时进行编译又称即时编译)通过对运行上下文的扫描经过逃逸分析去除不可能存在共享资源竞争的锁通过这种方式消除没有必要的锁可以节省毫无意义的请求锁时间

以上为个人经验希望能给大家一个参考也希望大家多多支持


相关文章

猜您喜欢

网友评论

Copyright 2020 www.sopisoft.net 【绿软下载站】 版权所有 软件发布

声明:所有软件和文章来自软件开发商或者作者 如有异议 请与本站联系 点此查看联系方式