Sychronized锁升降级、偏向锁、轻量级锁

Sychronized简介

首先synchronized 代码块是由一对儿 monitorenter/monitorexit 指令实现的，Monitor 对象是同步的基本实现

在Java6中,Monitor的实现完全是依靠操作系统的互斥锁，因为需要进行用户态到内核态的切换，所以同步操作是一个无差别的重量级操作。

近年来的JDK中,JVM对此进行了改进，提供了三种不同的Monitor实现，也就是通常所说的三种不同的锁：偏斜锁(偏向锁 Biased Locking)、轻量级锁和重量级锁，大大改进了性能。

首先来介绍一下sychronized的底层实现Monitor：

Monitor(锁)

Monitor被翻译为监视器和管程

每个Java对象都可以关联一个Monitor对象，如果使用synchronized对象上锁(重量级)之后，该对象头的Mark Word中就被设置指向Monitor对象的指针

• 刚开始Monitor中Owner为null
• 当Thread-2执行synchronized(obj)就会奖Monitor的所有Owner置为Thread-2，Monitor中只能有一个Owner
• 在Thread-2上锁过程中，如果Thread-3,Thread-4,Thread-5也来执行synchronized(obj)，就会进入EntryList BLOCKED
• Thread-2执行完同步代码块的内容，然后唤醒EntryList中等待的线程来竞争锁，竞争的时候是非公平的
• 图中WaitSet中的Thread-0,Thread-1是之前获得过锁，但条件不满足进入WAITING状态的线程

synchronized原理-轻量级锁

• 轻量级锁的使用场景：如果一个对象有很多线程访问，但多线程访问的时间是错开的(没有竞争)，那么可以使用轻量级锁来优化。
• 轻量级锁对使用者是透明的，即语法仍是synchronized
• 假设有两个方法同步块，利用同一个对象加锁

• 创建锁记录对象，每个线程的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的Mark Word

• 让锁记录中Object reference指向锁对象，并尝试用cas替换Object的Mark Word，将Mark Word的值存入锁记录

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dzqAity7-1627748072302)(https://cdn.nlark.com/yuque/0/2021/png/2692826/1626247984312-9cad0cab-3eab-4189-8c27-7e6f469afdd4.png)]

• 如果cas替换成功，对象头中存储了锁记录地址和状态00,表示由该线程给对象加锁，这时图示如下

• 如果cas失败，有两种情况

  • 如果是其他线程已经持有该Object的轻量级锁，这时表明有竞争，进入锁膨胀过程
  • 如果是自己执行了synchronized锁重入，那么再添加一条Lock Record作为重入的计数

• 当退出synchronized代码块（解锁时）如果有取值为null的锁记录，表示有重入，这时重置锁记录，表示重入计数减一

synchronized原理-锁膨胀

如果在尝试轻量级锁的过程中，CAS操作无法成功，这时一种情况就是有其他线程为此对象加上了轻量级锁(有竞争)，这时需要进行锁膨胀，将轻量级锁变为重量级锁。

• 当Thread-1进行轻量级加锁时，Thread-0已经对该对象加了轻量级锁

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wR6C5OKy-1627748072308)(https://cdn.nlark.com/yuque/0/2021/png/2692826/1626248730124-f455d399-1f42-4a8b-9146-8d28d6c07a23.png)]

• 这时Thread-1加轻量级锁失败，进入锁膨胀过程

• • 即为Object对象申请Monitor锁，让Object指向重量级锁地址
  • 然后自己进入Monitor的EntryListBLOCKED

• 当Thread-0退出同步块解锁时，使用cas将Mark Word的值恢复给对象头，然后进入重量级解锁流程，即按照Monitor地址找到Monitor对象，设置Owner为null,唤醒EntryList中BLOCKED线程

synchronized原理-自旋优化

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。

自旋重试成功的情况

自旋失败的情况

• 在Java6之后自旋锁时自适应的，比如对象刚刚的一次自旋操作成功过，那么认为此次自旋成功的可能性会高，就多自旋几次，反之，就少自旋甚至不自旋
• 自旋会占用CPU时间，单核CPU自旋就是浪费，多核CPU自旋才能发挥优势
• Java7之后不能控制是否开启自旋功能

synchronized原理-偏向锁

轻量级锁的缺点是在没有竞争时(就自己这个线程)，每次重入仍然需要执行CAS操作。

Java6中引入了偏向锁来做进一步优化：只有第一次使用CAS将线程ID设置到对象的Mark Word头，之后发现这个线程ID是自己的就表示没有竞争，不用重新CAS.以后只要不发生竞争，这个对象就归该线程所有

例如：

偏向锁-偏向状态

对象头格式

一个对象创建时：

• 如果开启了偏向锁（默认开启），那么对象创建后，markword值为0X05即最后3位为101，这时它的thread、epoch、age都为0
• 偏向锁时默认延迟的（5秒左右）。不会在程序启动时立即生效，如果想避免延迟，可以加VM参数XX:BiasedLockingStartupDelay=0禁用延迟生效
• 如果没有开启偏向锁，那么对象创建后，markword值为0x01即最后3位为001，这时它的hashcode、age都为0，第一次用到hashcode时才会赋值；禁用偏向锁命令:-XX:-UseBiasedLocking

偏向锁-撤销-调用hashCode方法

调用对象的hashcode方法会禁用偏向锁，因为如果处于偏向锁状态就没地方存储hash码，偏向锁的MarkWord中存储的是线程id

• 轻量级锁会在锁记录中记录hashcode
• 重量级锁会在Monitor中记录hashCode

在调用hashCode后使用偏向锁，记得去掉-XX:-UseBiasedLocking

偏向锁-撤销-其他线程使用对象

当有其他线程使用偏向锁对象时，会将偏向锁升级为轻量级锁

调用wait/notify也会撤销，会升级为重量级锁

偏向锁-批量重偏向

如果对象被多个线程访问，但没有竞争，这时偏向了线程T1的对象仍有机会重新偏向T2，重偏向会重置对象的ThreadID

当撤销偏向阈值超过20次后，jvm会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至加锁线程

偏向锁-批量撤销

当撤销偏向锁阈值超过40次后，jvm会觉得根本不该偏向，于是整个类的所有对象都会变为不可偏向，新建对象也是不可偏向的

锁消除

JIT会优化代码，如果加锁的对象不是共享对象，jit会取消加锁

Sychronized源码实现

在sharedRuntime.cpp中的代码体现了sychronized的主要逻辑。

Handle h_obj(THREAD, obj);
  if (UseBiasedLocking) {
    // Retry fast entry if bias is revoked to avoid unnecessary inflation
    ObjectSynchronizer::fast_enter(h_obj, lock, true, CHECK);
  } else {
    ObjectSynchronizer::slow_enter(h_obj, lock, CHECK);
  }

• UseBiasedLocking是一个检查，在jvm启动时，我们可以指定是否开启偏向锁

偏向所并不适合所有场景，在存在较多不会真正竞争的并发场景时，才会有明显性能改善，还有一方面是偏向锁会延缓JIT预热的进程，所以很多性能测试需要显式关闭偏向锁使用命令如下：

-XX:-UseBiasedLoking

继续回到上述代码：

• fast_enter是完整锁的获取路径，slow_enter则是绕过偏向锁直接获取轻量级锁

然后来看看fast_enter的具体实现，在synchronizer.cpp里能够看到：

void ObjectSynchronizer::fast_enter(Handle obj, BasicLock* lock,
                                  bool attempt_rebias, TRAPS) {
  //先判断是否开启了偏向锁
  if (UseBiasedLocking) {
    if (!SafepointSynchronize::is_at_safepoint()) {
      BiasedLocking::Condition cond = BiasedLocking::revoke_and_rebias(obj, attempt_rebias, THREAD);
      if (cond == BiasedLocking::BIAS_REVOKED_AND_REBIASED) {
        return;
      }
  } else {
      assert(!attempt_rebias, "can not rebias toward VM thread");
      BiasedLocking::revoke_at_safepoint(obj);
  }
    assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now");
  }
 
  slow_enter(obj, lock, THREAD);
}

代码逻辑分析：

• BiasedLocking定义了偏向锁的具体操作，revoke_and_rebias是获取偏向锁的入口方法，revoke_at_safepoint定义了当检测到安全点时的处理逻辑。
• slow_enter用来处理获取偏向锁失败的情况，失败后升级到轻量级锁，接下来继续来看slow_enter的代码

void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) {
  markOop mark = obj->mark();
 if (mark->is_neutral()) {
       // 将目前的Mark Word复制到Displaced Header上
  lock->set_displaced_header(mark);
  // 利用CAS设置对象的Mark Word
    if (mark == obj()->cas_set_mark((markOop) lock, mark)) {
      TEVENT(slow_enter: release stacklock);
      return;
    }
    // 检查存在竞争
  } else if (mark->has_locker() &&
             THREAD->is_lock_owned((address)mark->locker())) {
  // 清除
    lock->set_displaced_header(NULL);
    return;
  }
 
  // 重置Displaced Header
  lock->set_displaced_header(markOopDesc::unused_mark());
  ObjectSynchronizer::inflate(THREAD,
                            obj(),
                              inflate_cause_monitor_enter)->enter(THREAD);
}

这段代码描述了从试图获取轻量级锁，逐步进入到锁膨胀的过程。

• 设置Displaced Header,然后利用cas来设置对象的Mark Word，成功后就获取到了轻量级锁
• 否则Displaced Header,然后进入锁膨胀阶段，具体实现在Inflate中
• synchronized具体源码