美文网首页
synchronized实现原理和锁优化

synchronized实现原理和锁优化

作者: 长远勿见 | 来源:发表于2018-12-11 20:34 被阅读0次
    1. ObjectMonitor

    在HotSpot中,Monitor采用ObjectMonitor实现。

    Monitor是一个同步工具,通常被描述为一个对象。每一个Java对象都拥有一把看不见的Monitor锁
    Java中每个对象都拥有的监视器用来监测并发代码的重入,在非多线程编码时Monitor监视器不起作用,在synchronized范围内,监视器发挥作用

    ObjectMonitor的结构

    ObjectMonitor() {
        _header       = NULL;
        _count        = 0; //记录个数
        _waiters      = 0,
        _recursions   = 0;
        _object       = NULL;
       //指向持有ObjectMonitor对象的线程
        _owner        = NULL;
       //处于wait状态的线程,会被加入到_WaitSet
        _WaitSet      = NULL; 
        _WaitSetLock  = 0 ;
        _Responsible  = NULL ;
        _succ         = NULL ;
        _cxq          = NULL ;
        FreeNext      = NULL ;
        //处于等待锁block状态的线程,会被加入到该列表
        _EntryList    = NULL ; 
        _SpinFreq     = 0 ;
        _SpinClock    = 0 ;
        OwnerIsThread = 0 ;
      }
    

    2.synchronized实现原理

    synchronized在软件层面依赖JVM虚拟机实现同步;JUC包中的Lock同步锁在硬件层面依赖特殊的CPU指令实现同步。

    synchronized通过Monitor来实现线程同步,Monitor依赖于底层的操作系统的Mutex Lock(互斥锁)来实现的线程同步
    依赖底层操作系统的Mutex Lock所实现的锁称之为重量级锁

    同步代码块的同步原理
    synchronized同步代码块代码生成的字节码指令中包含monitorentermonitorexit指令。
    monitorenter指令:执行该指令时可以尝试去获取对象的monitor锁。当获得monitor时就会处于锁定状态,就可以去执行同步代码块。
    monitorexit指令:执行该指令会退出同步代码块并释放锁。执行该指令的线程是monitor的占有者。

    异常退出同步代码块时会释放锁,也会调用该指令。

    同步方法的同步原理
    同步方法的字节码指令中没有monitorentermonitorexit指令,是通过方法修饰符上的ACC_SYNCHRONIZED标识符来实现方法的同步

    同步方法是一种隐式的方式实现同步,不需要字节码指令来完成。
    同步代码块中monitorentermonitorexit指令的执行是JVM通过调用操作系统的互斥语句mutex实现的,被阻塞的线程会被挂起、等待重新调度,会导致在用户态和内核态切换。

    1. Java对象的对象头

    在HotSpot虚拟机中,对象在内存中的存储的布局可以分为3块区域:对象头、实例数据、对齐填充

    Java对象头
    对象头包括两部分信息:Mark Word和类型指针。
    Mark Word是实现轻量级锁和偏向锁的关键。

    类型指针:指向对象的类元数据的指针。
    Mark Word:用于存储对象自身的运行时数据,是实现轻量级锁和偏向锁的关键
    包括哈希码、GC分代年龄、锁状态标志线程持有的锁、偏向线程ID、偏向时间戳。
    是一个非固定的数据结构用以方便在小的空间存储更多的信息。
    会根据对象的状态复用自己的存储空间,就是说在运行期间Mark Work里存储的数据会随着锁标志位的变化而变化

    不同状态下Mark Word的结构
    1. Lock Record --锁记录

    Lock Record(锁记录):在线程的栈中创建,用来存储锁对象的Mark Word的拷贝。
    线程私有的数据结构,每一个线程都有一个可用的Lock Record列表。
    每一个被锁住的对象都会和一个Lock Record关联,对象头中的Mark Word指向Lock Record的起始地址,

    LockRecord的结构如下图

    Lock Record的结构.png

    Owner:当线程成功获得锁后存放线程的唯一标识
    EnterQ:关联一个互斥锁,阻塞所有竞争锁失败的线程。
    RcThis:表示在该线程获得的锁上blocked或waiting的所有线程的个数。
    Nest:重入锁的计数。
    HashCode:保存从对象头拷贝过来的HashCode值(可能包含GC age)。
    Candidate:只有两种值:0或1,表示没有需要唤醒的线程或表示要唤醒一个线程去竞争锁。

    1. 对synchronized实现机制进行的锁优化

    依赖操作系统Mutex Lock所实现的重量级锁在线程切换时会导致在用户态和内核态之间切换,会导致很大的开销。
    JDK6之后,引入了偏向锁轻量级锁来减少锁操作的开销。
    目前锁一共有4种状态,级别从低到高依次为:无锁、偏向锁、轻量级锁、重量级锁;锁状态只能升级不能降级
    偏向锁、轻量级锁属于乐观锁,重量级锁属于悲观锁。乐观锁CAS的实现同步,获取不到时会转换为悲观锁

    无锁
    没有对资源进行锁定,所有线程都可以访问并修改同一个资源,但只有一个线程可以修改成功。
    特点:修改操作在循环中进行。
    CAS原理及应用即是无锁的实现。

    偏向锁
    偏向于第一个访问锁的线程,如果在运行过程中,锁没有被其他线程访问,持有偏向锁的线程永远不会触发同步。
    偏向锁就是为了解决在不存在多线程竞争时,锁总是由同一个线程多次获得的情况。目的是在只有一个线程执行同步代码块时可以提高性能。

    加锁过程
    a.加锁发生在锁第一次被线程拥有时,会使用CAS原子操作尝试更新对象的Mark Word,将Mark Word中的偏向锁标志位改为1,并记录偏向线程的ID。
    之后在对象头中的偏向线程ID指向的线程进入和退出相同锁对象的同步代码块时不用通过CAS操作来更新对象头。
    撤销和膨胀过程
    b.另一个竞争线程想要进入同步代码块时,访问到Mark Word中偏向锁标志为1,确认是可偏向状态;同时检查到对象头中的偏向线程ID与该竞争线程不一致,竞争线程尝试进行CAS操作更新对象头。
    c.竞争线程更新对象头失败时,等待持有偏向锁线程进入安全点(会导致STW)并暂停持有偏向锁的线程,根据偏向锁线程是否处于同步代码块,处于同步代码块时将偏向锁升级为轻量级锁;已经退出同步代码块时,将锁置为无锁状态。
    d.竞争线程更新对象头成功时,直接进入同步代码块。

    偏向锁加锁撤销锁流程图:

    偏向锁.png

    适合在无锁竞争情况下使用,撤销偏向锁时会导致stop the world

    问题:为什么在到达全局安全点时才会进行偏向锁的释放?
    Epoch有关。

    轻量级锁
    轻量级锁是为了在线程交替执行同步代码块时提高性能,偏向锁是在只有一个线程执行同步块时提高性能。
    轻量级锁与偏向锁的不同:轻量级锁每次退出同步代码块都要释放锁,偏向锁只有在竞争发生时才会释放锁。

    加锁过程
    a.线程进入同步代码块时确定对象锁状态:即对象锁状态是无锁状态:对象头中Mark Word中的锁标志位为:“01”状态,偏向锁标志位为:“0”。
    b.确定对象锁的对象头为无锁状态后,在当前线程的栈帧中创建锁记录(Lock Record)空间,将锁对象对象头中的Mark Word复制到锁记录中
    c.Mark Word保存到锁记录成功后,使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针并将Lock Record锁记录里的owner指向对象的Mark Word
    CAS操作成功了:线程就拥有了对象的锁可以去执行同步代码块,并会将对象的锁标志设置为:“00”,即为轻量级锁。
    CAS操作失败了:先检查对象头Mark Word的指针有没有指向当前线程的锁记录Lock Record,指向了说明当前线程已经获得了锁,本次加锁是重入锁,当前线程可以直接进入同步块继续执行;否则线程会进入自旋状态,不断尝试去获取锁。

    • 轻量级锁每次进入与退出同步块时都要通过CAS操作更新对象头。

    锁释放过程
    d.线程退出同步代码块并释放锁是通过CAS操作来完成的,会用CAS操作将对象头中的Mark Word中记录的锁对象的指针替换为锁记录中复制的Mark Word
    CAS操作成功:同步操作完成,对象头设置为无锁状态(偏向锁为:“0”,锁标志位为:“01”)。
    CAS操作失败:此时持有轻量级锁的线程会将锁释放,唤醒阻塞的线程。
    CAS操作失败的原因:是因为没有得到锁的线程在超过了自旋次数还没有获得锁,进入阻塞状态,并将对象头的锁标志更改为:“10”(重量级锁),Mark Word中存储的是指向指向重量级锁的指针(互斥量)

    获得和释放轻量级锁的过程图如下:

    获得和释放轻量级锁的过程图.png

    问题1:为什么在升级为轻量级锁时要把对象头里的Mark Word复制到线程栈的锁记录中?
    在获得锁时:会将Mark Word值作为CAS比较的条件(CAS操作的三个值中的当前值)。只有锁记录复制的Mark Word值与对象锁的对象头中的Mark Word相等时,才会将对象头中的Mark Word中的内容替换为指向锁记录的指针,才可以获得锁。
    在释放锁时:通过该Mark Word可以判定是否在持有锁的过程中该对象锁被其他线程申请过,如果被申请过,则在释放锁的过程中唤醒被挂起的线程。

    问题2:为什么会尝试CAS不成功以及什么情况下会不成功?

    重量级锁
    如果在存在同一时间访问同一锁,就会导致轻量级锁膨胀为重量级锁。

    对象锁升级为重量级锁时,锁标志的状态值变为"10",Mark Word中存储的是指向重量级锁的指针(指针指向的是Monitor对象的起始地址),此时等待锁的线程都会进入阻塞状态。

    重量级锁通过对象内部的monitor监视器锁来实现。监视器锁是依赖于底层操作系统的Mutex Lock(互斥锁)来实现。

    总结:偏向锁是通过对比Mark Word解决加锁问题,避免多次执行CAS操作;轻量级锁通过CAS操作和自旋解决加锁问题,避免线程阻塞和唤醒而影响性能;重量级锁是将除了拥有锁的线程以外的线程都阻塞。

    1. 对synchronized实现机制进行的其他调整

    锁消除
    在进行同步控制时,JVM检测到不可能存在共享数据竞争,JVM就会对同步锁进行锁清除
    锁清除的依据是:逃逸分析的数据支持。

    锁粗化
    将多个连续的加锁、解锁操作连接在一起,扩展成一个范围更大的锁。

    相关文章

      网友评论

          本文标题:synchronized实现原理和锁优化

          本文链接:https://www.haomeiwen.com/subject/idfofqtx.html