Java中的偏向锁，轻量级锁，重量级锁解析

港控/mmm° 2021-06-10 20:38 523阅读 0赞

## 参考文章 ##

*  [Java并发编程：Synchronized底层优化（偏向锁、轻量级锁）][Java_Synchronized]
 *  [聊聊并发（二）Java SE1.6中的Synchronized][Java SE1.6_Synchronized]
 *  [Lock Lock Lock: Enter!][Lock Lock Lock_ Enter]
 *  [5 Things You Didn’t Know About Synchronization in Java and Scala][5 Things You Didn_t Know About Synchronization in Java and Scala]
 *  [Synchronization and Object Locking][]
 *  [Eliminating Synchronization-Related Atomic Operations with Biased Locking and Bulk Rebiasing][]

## Java 中的锁 ##

在 Java 中主要2种加锁机制:

*  `synchronized` 关键字
 *  `java.util.concurrent.Lock` （`Lock`是一个接口，`ReentrantLock`是该接口一个很常用的实现）

这两种机制的底层原理存在一定的差别

*  `synchronized` 关键字通过一对字节码指令 `monitorenter/monitorexit` 实现， 这对指令被 JVM 规范所描述。
 *  `java.util.concurrent.Lock` 通过 Java 代码搭配`sun.misc.Unsafe` 中的本地调用实现的

## 一些先修知识 ##

先修知识 1： **Java 对象头**

*  字宽（Word）: 内存大小的单位概念， 对于 32 位处理器 1 Word = 4 Bytes， 64 位处理器 1 Word = 8 Bytes
 *  每一个 Java 对象都至少占用 2 个字宽的内存(数组类型占用3个字宽)。
    
     *  第一个字宽也被称为对象头Mark Word。 对象头包含了多种不同的信息， 其中就包含对象锁相关的信息。
     *  第二个字宽是指向定义该对象类信息（class metadata）的指针
 *  非数组类型的对象头的结构如下图：![在这里插入图片描述][20190415101813830.png]
 *  说明：
    
     *  MarkWord 中包含对象 hashCode 的那种无锁状态是偏向机制被禁用时， 分配出来的无锁对象MarkWord 起始状态
     *  偏向机制被启用时，分配出来的对象状态是 ThreadId|Epoch|age|1|01, ThreadId 为空时标识对象尚未偏向于任何一个线程， ThreadId 不为空时， 对象既可能处于偏向特定线程的状态， 也有可能处于已经被特定线程占用完毕释放的状态， 需结合 Epoch 和其他信息判断对象是否允许再偏向（rebias）。

下面的图片来自参考论文[Eliminating Synchronization-Related Atomic Operations with Biased Locking and Bulk Rebiasing][]， 可以与上面的表格进行比对参照， 更为清晰, 可以看出来， 标志位（tag bits）可以直接确定唯一的一种锁状态

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlbmd4aWFvMTk5Mw_size_16_color_FFFFFF_t_70]

先修知识 2： **CAS** 指令

*  CAS （Compare And Swap） 指令是一个CPU层级的原子性操作指令。 在 Intel 处理器中， 其汇编指令为 cmpxchg。
 *  该指令概念上存在 3 个参数， 第一个参数【目标地址】， 第二个参数【值1】， 第三个参数【值2】， 指令会比较【目标地址存储的内容】和 【值1】 是否一致， 如果一致， 则将【值 2】 填写到【目标地址】， 其语义可以用如下的伪代码表示：

function cas(p , old , new ) returns bool {
        if *p ≠ old { // *p 表示指针p所指向的内存地址
            return false
        }
        *p ← new
        return true
    }

*  注意： 该指令是是原子性的， 也就是说 CPU 执行该指令时， 是不会被中断执行其他指令的

先修知识 3： “**CAS**”实现的"**无锁**"算法常见误区

*  误区一： 通过简单应用 “**比较后再赋值**” 的操作即可轻松实现很多无锁算法
    
     *  CAS 指令的一个不可忽略的特征是**原子性**。 在 CPU 层面， CAS 指令的执行是有原子性语义保证的， 如果 CAS 操作放在应用层面来实现， 则需要我们自行保证其原子性。 否则就会发生如下描述的问题：

// 下列的函数如果不是线程互斥的, 是错误的 CAS 实现
    function cas( p , old , new) returns bool {
        if *p ≠ old { // 此处的比较操作进行时， 可以同时有多个线程通过该判断
            return false
        }
        *p ← new // 多个线程的赋值操作会相互覆盖， 造成程序逻辑的错误
        return true
    }

*  误区二： CAS 操作的 ABA 问题
    
     *  大部分网络博文对 ABA 问题的常见描述是： 应用 CAS 操作时， 目标地址的值刚开始为 A， 工作线程/进程 读取后， 进行了一系列运算， 计算得出了新值 C， 在此期间， 目标地址的值被其他线程已经进行了不止一次修改， 其值已经从 A 被改为 B ， 又改回 A， 此时便会发生同步问题。
     *  上面的描述是其实是错误的， 思考一下就会发现， 如果工作线程的操作目的是将目标地址的值从 A 改为 C， 那么即便在这期间目标地址的值经过了其他线程或进程的多次修改， 其语义依旧是正确的。
     *  例如目前要将某银行账号的余额扣除 50， 通过 CAS 保证同步 ：
        
         *  首先读取原有余额为 100 ，
         *  计算余额应该赋值为 100 - 50 = 50
         *  此时该线程被挂起， 该账户同时又发生了转入 150 和转出 150 的操作， 余额经历了 100 -》250 -》100 的变动
         *  线程被唤醒， 进行 CAS 赋值操作 cas（p， 100， 50） ， 正常得以执行。
         *  该账户的余额依旧是正确的
     *  通过上述例子就可以发现， ABA 的问题并不在于多次修改。 查阅一下 CAS 的 wiki 解释， 就会发现， ABA 真正的问题是， 假如目标地址的内容被多次修改以后， 虽然**从二进制上来看是依旧是 A， 但是其语义已经不是 A** 。例如， 发生了整数溢出， 内存回收等等。

先修知识 4： **栈帧（Stack Frame）** 的概念

*  这个概念涉及的内容较多， 不便于展开叙述。 从理解下文的角度上来讲， 需要知道， 每个线程都有自己独立的内存空间， 栈帧就是其中的一部分。里面可以存储仅属于该线程的一些信息。
 *  需要深入了解的同学， 需要自行查阅 **栈帧** 相关的概念

先修知识 5： **轻量级加锁**的过程

*  （1）在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。
 *  （2）拷贝对象头中的Mark Word复制到锁记录中。这时候线程堆栈与对象头的状态如图2.1所示

![图2.1][2.1]

*  （3）拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤（4），否则执行步骤（5）。
 *  （4）如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图2.2所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlbmd4aWFvMTk5Mw_size_16_color_FFFFFF_t_70 1]

*  5）如果这个更新操作失败了，说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁

先修知识 6： **重量级加锁**的过程

*  轻量级锁在向重量级锁膨胀的过程中， 一个操作系统的互斥量（mutex）和条件变量( condition variable )会和这个被锁的对象关联起来。
 *  具体而言， 在锁膨胀时， 被锁对象的 markword 会被通过 CAS 操作尝试更新为一个数据结构的指针， 这个数据结构中进一步包含了指向操作系统互斥量(mutex) 和 条件变量（condition variable） 的指针

## synchronized 关键字之锁的升级（偏向锁->轻量级锁->重量级锁） ##

前面提到过， synchronized 代码块是由一对 **monitorenter/moniterexit** 字节码指令实现， monitor 是其同步实现的基础， Java SE1.6 为了改善性能， 使得 JVM 会根据竞争情况， 使用如下 3 种不同的锁机制

*  偏向锁（Biased Lock ）
 *  轻量级锁（ Lightweight Lock）
 *  重量级锁（Heavyweight Lock）

上述这三种机制的切换是根据竞争激烈程度进行的， 在几乎无竞争的条件下， 会使用偏向锁， 在轻度竞争的条件下， 会由偏向锁升级为轻量级锁， 在重度竞争的情况下， 会升级到重量级锁。

注意 JVM 提供了关闭偏向锁的机制， JVM 启动命令指定如下参数即可

-XX:-UseBiasedLocking

下图展现了一个对象在创建（allocate） 后， 根据偏向锁机制是否打开， 对象 MarkWord 状态以不同方式转换的过程

![这里写图片描述][70]

上图在参考文章一中的中文翻译对照图如下

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlbmd4aWFvMTk5Mw_size_16_color_FFFFFF_t_70 2]

## 无锁 -> 偏向锁 ##

![在这里插入图片描述][20190411144005423.png]

从上图可以看到 ， 偏向锁的获取方式是将对象头的 **MarkWord** 部分中， 标记上线程ID， 以表示哪一个线程获得了偏向锁。 具体的赋值逻辑如下：

*  首先读取目标对象的 MarkWord, 判断是否处于可偏向的状态（如下图）

![这里写图片描述][70 1]

下面是 [Open Jdk/ JDK 8 源码][Open Jdk_ JDK 8] 中检测一个对象是否处于可偏向状态的源码

// Indicates that the mark has the bias bit set but that it has not
      // yet been biased toward a particular thread
      bool is_biased_anonymously() const {
        return (has_bias_pattern() && (biased_locker() == NULL));
      }
    
    
    // Biased Locking accessors.
      // These must be checked by all code which calls into the
      // ObjectSynchronizer and other code. The biasing is not understood
      // by the lower-level CAS-based locking code, although the runtime
      // fixes up biased locks to be compatible with it when a bias is
      // revoked.
      bool has_bias_pattern() const {
        return (mask_bits(value(), biased_lock_mask_in_place) == biased_lock_pattern);
      }
      JavaThread* biased_locker() const {
        assert(has_bias_pattern(), "should not call this otherwise");
        return (JavaThread*) ((intptr_t) (mask_bits(value(), ~(biased_lock_mask_in_place | age_mask_in_place | epoch_mask_in_place))));
      }

*  has\_bias\_pattern() 返回 true 时代表 markword 的可偏向标志 bit 位为 1 ，且对象头末尾标志为 01。
 *  biased\_locker() == NULL 返回 true 时代表对象 Mark Word 中 bit field 域存储的 Thread Id 为空。
 *  如果为可偏向状态, 则尝试用 CAS 操作， 将自己的线程 ID 写入MarkWord
    
     *  如果 CAS 操作成功（状态转变为下图）， 则认为已经获取到该对象的偏向锁， 执行同步块代码 。 注意， age 后面的标志位中的值并没有变化， 这点之后会用到
     *  补充： 一个线程在执行完同步代码块以后， 并不会尝试将 MarkWord 中的 thread ID 赋回原值 。这样做的好处是： 如果该线程需要再次对这个对象加锁，而这个对象之前一直没有被其他线程尝试获取过锁，依旧停留在可偏向的状态下， 即可在不修改对象头的情况下， 直接认为偏向成功。
     *  ![这里写图片描述][70 2]
     *  如果 CAS 操作失败， 则说明， 有另外一个线程 Thread B 抢先获取了偏向锁。 这种状态说明该对象的竞争比较激烈， 此时需要撤销 Thread B 获得的偏向锁，将 Thread B 持有的锁升级为轻量级锁。 该操作需要等待全局安全点 JVM safepoint ( 此时间点， 没有线程在执行字节码) 。
 *  如果是**已偏向状态**， 则检测 MarkWord 中存储的 thread ID 是否等于当前 thread ID 。
    
     *  如果相等， 则证明本线程已经获取到偏向锁， 可以直接继续执行同步代码块
     *  如果不等， 则证明该对象目前偏向于其他线程， 需要**撤销**偏向锁

从上面的偏向锁机制描述中，可以注意到

*  偏向锁的 **撤销（revoke）** 是一个很特殊的操作， 为了执行撤销操作， 需要等待全局安全点（Safe Point）， 此时间点所有的工作线程都停止了**字节码**的执行。

## 偏向锁的撤销（Revoke） ##

如上文提到的， 偏向锁的撤销（Revoke） 操作并不是将对象恢复到无锁可偏向的状态， 而是在偏向锁的获取过程中， 发现了竞争时， 直接将一个被偏向的对象“升级到” 被加了轻量级锁的状态。 这个操作的具体完成方式如下：

*  在偏向锁 CAS 更新操作失败以后， 等待到达全局安全点。
    
     *  通过 MarkWord 中已经存在的 Thread Id 找到成功获取了偏向锁的那个线程, 然后在该线程的栈帧中补充上轻量级加锁时， 会保存的锁记录（Lock Record）， 然后将被获取了偏向锁对象的 MarkWord 更新为指向这条锁记录的指针。
     *  至此， 锁撤销操作完成， 阻塞在安全点的线程可以继续执行。

## 偏向锁的批量再偏向（Bulk Rebias）机制 ##

偏向锁这个机制很特殊， 别的锁在执行完同步代码块后， 都会有释放锁的操作， 而偏向锁并没有直观意义上的“释放锁”操作。

那么作为开发人员， 很自然会产生的一个问题就是， 如果一个对象先偏向于某个线程， 执行完同步代码后， 另一个线程就不能直接重新获得偏向锁吗？ 答案是可以， JVM 提供了批量再偏向机制（Bulk Rebias）机制

该机制的主要工作原理如下：

*  引入一个概念 epoch, 其本质是一个时间戳 ， 代表了偏向锁的有效性
 *  从前文描述的对象头结构中可以看到， epoch 存储在可偏向对象的 MarkWord 中。
 *  除了对象中的 epoch, 对象所属的类 class 信息中， 也会保存一个 epoch 值
 *  每当遇到一个全局安全点时， 如果要对 class C 进行批量再偏向， 则首先对 class C 中保存的 epoch 进行增加操作， 得到一个新的 epoch\_new
 *  然后扫描所有持有 class C 实例的线程栈， 根据线程栈的信息判断出该线程是否锁定了该对象， 当有线程锁定了该对象时，将 epoch\_new 的值赋给被锁定的对象中，更新值。
 *  退出安全点后， 当有线程需要尝试获取偏向锁时， 直接检查 class C 中存储的 epoch 值是否与目标对象中存储的 epoch 值相等， 如果不相等， 则说明该对象的偏向锁已经无效了， 可以尝试对此对象重新进行偏向操作。

简而言之，在安全点检查持有C实例的线程栈，如果有的话，将C实例中的epoch值更新，代表还有线程锁定中。

上述的逻辑可以在 JDK 源码中得到验证。

[sharedRuntime.cpp][]

在 sharedRuntime.cpp 中， 下面代码是 synchronized 的主要逻辑

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 启动时， 偏斜锁是否启用的标志。
 *  fast\_enter 中包含了偏斜锁的相关逻辑
 *  slow\_enter 中绕过偏斜锁， 直接进入轻量级锁获取

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);
    }

*  该函数中再次保险性地做了偏斜锁是否开启的检查（UseBiasedLocking）
 *  当系统不处于安全点时， 代码通过方法 revoke\_and\_rebias 这个函数尝试获取偏斜锁， 如果获取成功就可以直接返回了， 如果不成功则进入轻量级锁的获取过程
 *  revoke\_and\_rebias 这个函数名称就很有意思， 说明该函数中包含了 revoke 的操作也包含了 rebias 的操作
    
     *  revoke 不是只应该在安全点时刻才发生吗？ 答案： 有一些特殊情形， 不需要安全点也可以执行 revoke 操作
     *  此处为什么只有 rebias 操作， 没有初次的 bias 操作？答案： 首次的 bias 操作也被当成了 rebias 操作的一个特例

revoke\_and\_rebias 函数的定义在 [biasedLocking.cpp][]

BiasedLocking::Condition BiasedLocking::revoke_and_rebias(Handle obj, bool attempt_rebias, TRAPS) {
      assert(!SafepointSynchronize::is_at_safepoint(), "must not be called while at safepoint");
    
      // We can revoke the biases of anonymously-biased objects
      // efficiently enough that we should not cause these revocations to
      // update the heuristics because doing so may cause unwanted bulk
      // revocations (which are expensive) to occur.
      markOop mark = obj->mark();
      if (mark->is_biased_anonymously() && !attempt_rebias) {
          /* 
    		    进一步查看源码可得知， is_biased_anonymously() 为 true 的条件是对象处于可偏向状态， 
    		    且 线程ID  为空， 表示尚未偏向于任意一个线程。 
    		    此分支是进行对象的 hashCode 计算时会进入的， 根据 markWord 结构可以看到， 
    		    当一个对象处于可偏向状态时， markWord 中 hashCode 的存储空间是被占用的
    		    所以需要 revoke 可偏向状态， 以提供存储 hashCode 的空间
    		 */
        
        // We are probably trying to revoke the bias of this object due to
        // an identity hash code computation. Try to revoke the bias
        // without a safepoint. This is possible if we can successfully
        // compare-and-exchange an unbiased header into the mark word of
        // the object, meaning that no other thread has raced to acquire
        // the bias of the object.
        markOop biased_value       = mark;
        markOop unbiased_prototype = markOopDesc::prototype()->set_age(mark->age());
        markOop res_mark = obj->cas_set_mark(unbiased_prototype, mark);
        if (res_mark == biased_value) {
          return BIAS_REVOKED;
        }
      } else if (mark->has_bias_pattern()) {
        Klass* k = obj->klass();
        markOop prototype_header = k->prototype_header();
        if (!prototype_header->has_bias_pattern()) {
          // This object has a stale bias from before the bulk revocation
          // for this data type occurred. It's pointless to update the
          // heuristics at this point so simply update the header with a
          // CAS. If we fail this race, the object's bias has been revoked
          // by another thread so we simply return and let the caller deal
          // with it.
          markOop biased_value       = mark;
          markOop res_mark = obj->cas_set_mark(prototype_header, mark);
          assert(!obj->mark()->has_bias_pattern(), "even if we raced, should still be revoked");
          return BIAS_REVOKED;
        } else if (prototype_header->bias_epoch() != mark->bias_epoch()) { 
          // The epoch of this biasing has expired indicating that the
          // object is effectively unbiased. Depending on whether we need
          // to rebias or revoke the bias of this object we can do it
          // efficiently enough with a CAS that we shouldn't update the
          // heuristics. This is normally done in the assembly code but we
          // can reach this point due to various points in the runtime
          // needing to revoke biases.
          if (attempt_rebias) {
    	    /*
    			下面的代码就是尝试通过 CAS 操作， 将本线程的 ThreadID 尝试写入对象头中
    		*/
            assert(THREAD->is_Java_thread(), "");
            markOop biased_value       = mark;
            markOop rebiased_prototype = markOopDesc::encode((JavaThread*) THREAD, mark->age(), prototype_header->bias_epoch());
            markOop res_mark = obj->cas_set_mark(rebiased_prototype, mark);
            if (res_mark == biased_value) {
              return BIAS_REVOKED_AND_REBIASED;
            }
          } else {
            markOop biased_value       = mark;
            markOop unbiased_prototype = markOopDesc::prototype()->set_age(mark->age());
            markOop res_mark = obj->cas_set_mark(unbiased_prototype, mark);
            if (res_mark == biased_value) {
              return BIAS_REVOKED;
            }
          }
        }
      }

## 偏向锁 -> 轻量级锁 ##

从之前的描述中可以看到， 存在超过一个线程竞争某一个对象时， 会发生偏向锁的撤销操作。 有趣的是， 偏向锁撤销后， 对象可能处于两种状态。

*  一种是**不可偏向的无锁状态**， 如下图（之所以不允许偏向， 是因为已经检测到了多于一个线程的竞争， 升级到了轻量级锁的机制）  
    ![这里写图片描述][70 3]
 *  另一种是**不可偏向的已锁 ( 轻量级锁) 状态**  
    ![这里写图片描述][70 4]

之所以会出现上述两种状态， 是因为偏向锁**不存在解锁的操作**， 只有**撤销**操作。 触发**撤销**操作时：

*  原来已经获取了偏向锁的线程可能已经执行完了同步代码块， 使得对象处于 “闲置状态”，相当于原有的偏向锁已经过期无效了。此时该对象就应该被直接转换为不可偏向的无锁状态。
 *  原来已经获取了偏向锁的线程也可能尚未执行完同步代码块， 偏向锁依旧有效， 此时对象就应该被转换为被轻量级加锁的状态

轻量级加锁过程：

*  首先根据标志位判断出对象状态处于不可偏向的无锁状态( 如下图）

![这里写图片描述][70 3]

*  在当前线程的栈桢（Stack Frame）中创建用于存储锁记录（lock record）的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。如果在此过程中发现，
 *  然后线程尝试使用 CAS 操作将对象头中的 Mark Word 替换为指向锁记录的指针。
    
     *  如果成功，当前线程获得锁
     *  如果失败，表示该对象已经被加锁了， 先进行自旋操作， 再次尝试 CAS 争抢， 如果仍未争抢到， 则进一步升级锁至重量级锁。

下图引用自博文  [聊聊并发（二）Java SE1.6中的Synchronized][Java SE1.6_Synchronized]展示了两个线程竞争锁， 最终导致锁膨胀为重量级锁的过程。

\*\*注意： **下图中第一个标绿 MarkWord 的起始状态是`HashCode|age|0|01` 是偏向锁未被启用时， 分配对象后的状态， 所以在图中并没有偏向锁这一流程的体现， 是直接从无锁状态进入了轻量级锁的状态**

![这里写图片描述][70 5]

## 重量级锁 ##

重量级锁依赖于操作系统的互斥量（mutex） 实现， 其具体的详细机制此处暂不展开， 日后可能补充。 此处暂时只需要了解该操作会导致进程从用户态与内核态之间的切换， 是一个开销较大的操作。

## 锁的优缺点对比 ##

<table> 
 <tbody> 
 <tr> 
 <td> 锁 </td> 
 <td> 优点 </td> 
 <td> 缺点 </td> 
 <td> 适用场景 </td> 
 </tr> 
 <tr> 
 <td> 偏向锁 </td> 
 <td> 加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距。 </td> 
 <td> 如果线程间存在锁竞争，会带来额外的锁撤销的消耗。 </td> 
 <td> 适用于只有一个线程访问同步块场景。 </td> 
 </tr> 
 <tr> 
 <td> 轻量级锁 </td> 
 <td> 竞争的线程不会阻塞，提高了程序的响应速度。 </td> 
 <td> 如果始终得不到锁竞争的线程使用自旋会消耗CPU。 </td> 
 <td> 追求响应时间。 同步块执行速度非常快。 </td> 
 </tr> 
 <tr> 
 <td> 重量级锁 </td> 
 <td> 线程竞争不使用自旋，不会消耗CPU。 </td> 
 <td> 线程阻塞，响应时间缓慢。 </td> 
 <td> 追求吞吐量。 同步块执行速度较长。 </td> 
 </tr> 
 </tbody> 
</table>

[Java_Synchronized]: http://www.cnblogs.com/paddix/p/5405678.html
[Java SE1.6_Synchronized]: http://www.infoq.com/cn/articles/java-se-16-synchronized
[Lock Lock Lock_ Enter]: http://jpbempel.blogspot.com/2013/03/lock-lock-lock-enter.html
[5 Things You Didn_t Know About Synchronization in Java and Scala]: https://blog.takipi.com/5-things-you-didnt-know-about-synchronization-in-java-and-scala/
[Synchronization and Object Locking]: https://wiki.openjdk.java.net/display/HotSpot/Synchronization
[Eliminating Synchronization-Related Atomic Operations with Biased Locking and Bulk Rebiasing]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.8487&rep=rep1&type=pdf
[20190415101813830.png]: /images/20210527/7de627dc70ae4825b75488dce25259ee.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlbmd4aWFvMTk5Mw_size_16_color_FFFFFF_t_70]: /images/20210527/e89a5f6363fa4400b5813fefa3918fbd.png
[2.1]: /images/20210527/83a213c5fc2e42938fe27ff03a9bce56.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlbmd4aWFvMTk5Mw_size_16_color_FFFFFF_t_70 1]: /images/20210527/39e3bf4eeeee43cdb15ae05aef2a334a.png
[70]: /images/20210527/b982d165d45e4a81973246dcb760a820.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlbmd4aWFvMTk5Mw_size_16_color_FFFFFF_t_70 2]: /images/20210527/92a2bd76d2704ff4a8810931b5f37e1d.png
[20190411144005423.png]: /images/20210527/221e1579678c402c8466a506481d1489.png
[70 1]: /images/20210527/187bea76446c47dda7b97f2dfd934009.png
[Open Jdk_ JDK 8]: http://hg.openjdk.java.net/
[70 2]: /images/20210527/9ffe422224094171b066cc16d84cfb88.png
[sharedRuntime.cpp]: http://hg.openjdk.java.net/jdk/jdk/file/6659a8f57d78/src/hotspot/share/runtime/sharedRuntime.cpp
[biasedLocking.cpp]: http://hg.openjdk.java.net/jdk/jdk/file/6659a8f57d78/src/hotspot/share/runtime/biasedLocking.cpp
[70 3]: /images/20210527/11b4a9be75b1434ea5b5b4b38a9bff26.png
[70 4]: /images/20210527/45815bdbb8a14fc8a25b7d164b7d8f10.png
[70 5]: /images/20210527/5d5a55a3152147a9bded77bd704de9a3.png