三、synchronized 锁升级

JDK 早期，synchronized 是重量级锁，效率比较低。重量级锁：申请资源必须经过 kernel (内核也叫操作系统)，系统调用。

JDK1.6 为了减少获取锁和释放锁带来的性能消耗，引入了偏向锁和轻量级锁，在 JDK1.6 中，锁一共有 4 种状态，级别从低到高一次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，目的是为了提高获取锁和释放锁的效率。

1、自旋锁与自适应自旋

互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态完成，这些操作给 Java 虚拟机的并发性能带来了很大的压力。同时，虚拟机的开发团队也注意到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。如果物理机器有一个以上的处理器，能让两个或以上的线程并行执行，我们就可以让后面请求锁的那个线程稍等一会，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

自旋锁在 JDK1.4.2 中就已经引入，只不过默认是关闭的，可以使用 -XX:+UseSpinning 参数来开启，在 JDK6 中改为默认开启了。自旋等待不能代替阻塞，且先不说对处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的。所以如果锁被占用的时间很短，自旋等待的效果会非常好；反之，自旋的线程只会白白消耗处理器资源，而不会做任何有价值的工作，这就会带来性能的浪费。因此自旋等待的时间必须有一定的限定，如果自旋超过了限定的次数，仍然没有成功获得锁，就应当使用传统的方式去挂起线程。自旋次数的默认是十次，用户也可以使用参数 -XX:PreBlockSpin 来自行更改。

不过无论是默认值还是用户指定的自旋次数，对整个 Java 虚拟机中所有的锁来说都是相同的。在 JDK6 中对自旋锁的优化，引入了自适应的自旋。自适应意味着自旋的时间不再是固定的了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而允许自旋等待持续相对更长的时间，比如持续 100 次循环。另一方面，如果对于某个锁，自旋很少成功获得过锁，那在以后要获取这个锁时，将有可能直接省略掉自旋的过程，以避免浪费处理器资源。有了自适用的自旋，随着程序运行时间的增长及性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越精准，虚拟机就会变得越来越聪明。

2、锁消除 lock eliminate

锁消除是指在虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去被其他线程访问到，那么就可以把它们当做栈上数据对待，认为这是线程私有的，同步加锁自然是无需进行的。可以先看下下面这段代码：

public void add(String str1,String str2){
         StringBuffer sb = new StringBuffer();
         sb.append(str1).append(str2);
}

代码中的 StringBuffer.append 方法被 synchronized 修饰过，锁就是 sb 对象。JVM 观察变量 sb，很快就会发现它的动态作用域被限制在 add 方法内部。也就是说，sb 这个引用只会在 add 方法中使用，永远不会逃逸到该方法之外，不可能被其它线程引用（因为是局部变量，栈私有）。因此，虽然这里有锁，但是可以被安全地消除掉。在即时编译之后，这段代码就回忽略掉所有的同步锁而直接执行了。

3、锁粗化 lock coarsening

public String test(String str){
       int i = 0;
       StringBuffer sb = new StringBuffer():
       while(i < 100){
           sb.append(str);
           i++;
       }
       return sb.toString():
}

原则上，我们在编写代码的时候，总是推荐将同步代码块的作用范围限制得尽量小；只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数据量尽可能变小；如果存在锁竞争，那等待的线程也能尽快拿到锁。

实际开发中就会遇到上个面的代码，JVM 会检测到这样一连串的操作都对同一个对象 sb 加锁（while 循环内 append 执行了 100 次，没有锁粗化的就要进行 100 次加锁/解锁）。此时 JVM 就会将加锁的范围粗化到这一连串的操作的外部（比如 while 循环体外），使得这一连串操作只需要加一次锁即可。

4、轻量级锁

轻量级锁是 JDK6 时加入的新型锁机制，它名字中轻量级是相对于使用操作系统互斥量来实现的传统而言的，因此传统的锁机制就被称为重量级锁。轻量级锁并不是用来代替重量级的，它设计的初衷是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

4.1、轻量级锁加锁

轻量级锁的工作过程，在线程即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位： 01），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象当前的 Mark Word 的拷贝（官方为这份拷贝加了一个 Displaced 前缀，即 Displaced Mark Word），这时候线程堆栈与对象头的状态如图，轻量级锁 CAS 操作之前的堆栈与对象的状态。

然后虚拟机将使用 CAS 操作尝试把对象的 Mark Word 更新为指向 Lock Record 的指针。如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象 Mark Word 锁标志位将变为 00，表示此对象处于轻量级锁定状态。轻量级锁 CAS 操作之后堆栈与对象的状态如图。

如果这个更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的 Mark Word 是否指向当前线程的栈帧，如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了，否则就说明这个锁对象已经被其他线程抢占了。如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁（锁标志的状态值为 10），此时 Mark Word 中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也必须进入阻塞状态。

升级重量级锁，需要向操作系统申请资源 linux mutex, CPU 从 3 级到 0 级系统调用，线程挂起，进入等待队列，等待操作系统的调度，然后再映射回用户空间。

4.2、轻量级锁解锁

轻量级锁解锁的过程同样是 CAS 操作来进行的，如果对象的 Mark Word 仍然指向线程的锁记录，那就使用 CAS 操作把对象当前的 Mark Word 和线程中复制的 Displaced Mark Word 替换回来。如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。如图是两个线程同时争夺锁，导致锁膨胀的流程图。

因为自旋会消耗 CPU，为了避免无用的自旋（比如获得锁的线程阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，就会被阻塞，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就回进行新一轮的夺锁之争。

5、偏向锁

偏向锁的目的是消除数据在无竞争情况下的同步，进一步提高系统性能。如果说轻量级锁实在无竞争的情况下使用 CAS 操作去消除同步的互斥量，那偏向锁就是在无竞争下的情况下把整个同步都消除掉，连 CAS 操作都不做了。这个锁会偏向于第一个获得它的线程，如果接下来的执行过程中，该锁没有其他线程获取，则持有偏向锁的线程将永远不需要再进行同步。

假设当前虚拟机启用了偏向锁（启用参数 -XX:+UseBiasedLocking，这是 JDK 1.6 起的默认值），那么当对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为 01，把偏向位设置为 1，进入偏向模式。同时使用 CAS 操作把获取到这个锁的线程 ThreadId 记录在对象的 Mark Word 之中。如果 CAS 操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机可以不再进行任何同步操作（例如 Locking、Unlocking 及对 Mark Word 的更新操作等）。

5.1 偏向锁的撤销

偏向锁使用了一种等到竞争出现释放锁的机制，所以其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有正在执行的字节码）。它会首先暂停拥有偏向锁的线程，然后检查持有偏向所得线程是否活着，如果线程不处于活动状态，则对象头设置成无锁状态；如果仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的 Mark Word 要么偏向其他线程，要么恢复到无锁或者标记对象不合适作为偏向锁，最后唤醒暂停的线程。如图，线程一演示了偏向锁初始化流程，线程二演示了偏向锁撤销的流程。

这里可能会出现一个问题：当对象进入偏向状态的时候，Mark Word 大部分的空间（23bit）都用于存储持有锁的 ThreadId 了，这部分空间占用了原有存储对象 HashCode 的位置，那原来对象的 HashCode 怎么办呢？

在 Java 语言里，一个对象如果计算过 HashCode，就应该一直保持该值不变，否则很多依赖对象 HashCode 的 API 都可能存在风险。而作为绝大多对象 HashCode 来源的 Object::hashCode 方法，返回的是独享的一致性哈希码（Identity Hash Code），这个值是能强制保证不变的，它通过在对象头中存储计算结果来保证第一次计算之后，再次调用该方法取到的 HashCode 永远不会再发生改变。

因此，当一个对象已经计算过一致性 HashCode 后，它就再也无法进入偏向锁的状态了；而当一个对象当前正处于偏向锁状态，又收到计算其一致性 HashCode 的请求时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁。在重量级锁的实现中，对象头指向了重量级锁的位置，代表重量级锁的 ObjectMonitor 类里有字段可以记录非加锁状态（标志位为 01）下的 Mark Word，其中自然可以存储原来的 HashCode。

轻量级锁、重量级锁的 hashCode 存在什么地方？ 线程栈中，轻量级锁的 LR 中，或是代表重量级锁的 ObjectMonitor 的成员中

5.2、关闭偏向锁

偏向锁在 JDK 1.6 里默认是启用的，但是他在应用程序启动几秒之后才激活，如果有必要可以使用 JVM 参数来关闭延迟： -XX:BiasedLockingStartupDelay=0。如果你确定应用程序里大多数的锁总是被不同的线程访问，那偏向锁就是多余的。偏向锁由于有锁撤销的过程，会消耗系统资源，所以，在锁争用特别激烈的时候，用偏向锁未必效率高，不如直接使用轻量级锁。这里可以通过 JVM 参数关闭偏向锁：-XX:-UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。

默认情况，偏向锁时延是4秒 因为 JVM 虚拟机自己有一些默认启动的线程，里面有好多 sync 代码，这些 sync 代码启动时就知道肯定会有竞争，如果使用偏向锁，就会造成偏向锁不断的进行锁撤销和锁升级的操作，效率较低。

6、总结

6.1、锁优缺点比较

6.2、为什么有自旋锁还需要重量级锁？

1. 自旋是消耗 CPU 资源的，如果锁的时间长，或者自旋线程多，CPU 会被大量消耗
2. 重量级锁有等待队列，所有拿不到锁的进入等待队列，不需要消耗 CPU 资源
3. 自旋次数默认值是 10 次，用可以使用参数 -XX:PreBlockSpin 来更改

6.3、偏向锁是否一定比自旋锁效率高？

1. 不一定，在明确知道会有多线程竞争的情况下，偏向锁肯定会涉及锁撤销，这时候直接使用自旋锁
2. JVM 启动过程，会有很多线程竞争（明确），所以默认情况启动时不打开偏向锁，过一段儿时间再打开

6.4、synchronized vs CAS

1. 在高争用，高耗时的环境下 synchronized 效率更高
2. 在低争用，低耗时的环境下 CAS 效率更高
3. synchronized 到重量级之后是等待队列不消耗 CPU
4. CAS 等待期间消耗 CPU

6.5、锁的状态转化及对象 Mark Word 的关系

上面偏向锁指的就是，把 Mark Word 的 ThreadId 改为自己线程的 ThreadId 的过程。偏向锁、轻量级锁的状态转化及对象 Mark Word 的关系如图所示

7、关于 epoch

7.1、批量重偏向与批量撤销

从偏向锁的加锁解锁过程中可看出，当只有一个线程反复进入同步块时，偏向锁带来的性能开销基本可以忽略，但是当有其他线程尝试获得锁时，就需要等到 safe point 时，再将偏向锁撤销为无锁状态或升级为轻量级，会消耗一定的性能，所以在多线程竞争频繁的情况下，偏向锁不仅不能提高性能，还会导致性能下降。于是，就有了批量重偏向与批量撤销：

1. 批量重偏向（bulk rebias）：当一个线程创建了大量对象并执行了初始的同步操作，后来另一个线程也来将这些对象作为锁对象进行操作，会导致偏向锁重偏向的操作。
2. 批量撤销（bulk revoke）：在多线程竞争剧烈的场景下，使用偏向锁定会导致性能下，偏向锁会撤销升级。

7.2、epoch 与 批量重偏向/撤销的关系

以 class 为单位，为每个 class 维护一个偏向锁撤销计数器，每一次该 class 的对象发生偏向撤销操作时，该计数器+1，当这个值达到重偏向阈值（默认 20）时，JVM 就认为该 class 的偏向锁有问题，因此会进行批量重偏向。每个 class 对象会有一个对应的 epoch 字段，每个处于偏向锁状态对象的 Mark Word 中也有该字段，其初始值为创建该对象时 class 中的 epoch 的值。每次发生批量重偏向时，就将该值 +1，同时遍历 JVM 中所有线程的栈，找到该 class 所有正处于加锁状态的偏向锁，将其 epoch 字段改为新值。下次获得锁时，发现当前对象的 epoch 值和 class 的 epoch 不相等，那就算当前已经偏向了其他线程，也不会执行撤销操作，而是直接通过 CAS 操作将其 Mark Word 的 ThreadId 改成当前线程 Id。

当达到重偏向阈值后，假设该 class 计数器继续增长，当其达到批量撤销的阈值后（默认 40），JVM 就认为该 class 的使用场景存在多线程竞争，会标记该 class 为不可偏向，之后，对于该 class 的锁，直接走轻量级锁的逻辑。

7.3、示例分析

这里可以通过设置 JVM 参数：-XX:+PrintFlagsFinal打印 JVM 默认参数。JVM 默认的批量重偏向和批量撤销的阈值分别是 20 和 40，如图所示。我们也可以手动设置 -XX:BiasedLockingBulkRebiasThreshold 和 -XX:BiasedLockingBulkRevokeThreshold 的参数。

7.3.1、批量重偏向

package com.yj.sync;
import org.openjdk.jol.info.ClassLayout;
import java.util.ArrayList;
import java.util.List;
/**
 * @description: 批量重偏向
 * @author: erlang
 * @since: 2021-01-30 23:35
 */
public class BulkRebias {
    private static class LockObject {
    }
    public static void main(String[] args) throws Exception {
        // 延时产生可偏向对象
        Thread.sleep(5000);
        // 创造 100 个偏向线程 t1 的偏向锁
        List<LockObject> locks = new ArrayList<>();
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 100; i++) {
                LockObject lock = new LockObject();
                synchronized (lock) {
                    locks.add(lock);
                }
            }
            try {
                // 为了防止 JVM 线程复用，在创建完对象后，保持线程 t1 状态为存活
                Thread.sleep(100000000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
        t1.start();
        // 睡眠 3s 钟保证线程 t1 创建对象完成
        t1.sleep(3000);
        System.out.println("打印 t1 线程，locks 中第 20 个对象的对象头：");
        System.out.println((ClassLayout.parseInstance(locks.get(19)).toPrintable()));
        // 创建线程 t2 竞争线程 t1 中已经退出同步块的锁
        Thread t2 = new Thread(() -> {
            // 这里面只循环了 40 次！！！
            for (int i = 0; i < 40; i++) {
                LockObject lock = locks.get(i);
                synchronized (lock) {
                    // 分别打印第 19 次和第 20 次偏向锁重偏向结果
                    if (i == 18 || i == 19) {
                        System.out.println("第 " + (i + 1) + " 次偏向结果");
                        System.out.println((ClassLayout.parseInstance(lock).toPrintable()));
                    }
                }
            }
            try {
                Thread.sleep(10000000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
        t2.start();
        Thread.sleep(3000);
        System.out.println("打印 locks 中第 11 个对象的对象头：");
        System.out.println((ClassLayout.parseInstance(locks.get(10)).toPrintable()));
        System.out.println("打印 locks 中第 26 个对象的对象头：");
        System.out.println((ClassLayout.parseInstance(locks.get(25)).toPrintable()));
        System.out.println("打印 locks 中第 41 个对象的对象头：");
        System.out.println((ClassLayout.parseInstance(locks.get(40)).toPrintable()));
    }
}

示例代码中，线程 t1 创造了 100 个对象，并执行了同步操作，即创建了 100 个偏向锁。如图是第 20 个对象的对象头信息，偏向的线程 t1。

重偏向结果，线程 t2，前 19 次偏向均产生了轻量级锁，而到第 20 次的时候，达到了批量重偏向的阈值 20，此时锁并不是轻量级锁，而变成了偏向锁，此时偏向的线程 t2。

偏向结束后的对象头信息，前 20 个对象，并没有触发批量重偏向机制，线程 t2 执行释放同步锁后，转变为无锁形态；第 20 到 40 个对象，触发了批量重偏向机制，对象为偏向状态，偏向线程 t2。第 41 个对象之后，没有触发批量重偏向机制，对象仍偏向线程 t1。

7.3.2、批量撤销

package com.yj.sync;
import org.openjdk.jol.info.ClassLayout;
import java.util.ArrayList;
import java.util.List;
/**
 * @description: 批量撤销
 * @author: erlang
 * @since: 2021-01-31 09:35
 */
public class BulkRevoke {
    private static class LockObject {
    }
    public static void main(String[] args) throws Exception {
        Thread.sleep(5000);
        List<LockObject> locks = new ArrayList<>();
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 100; i++) {
                LockObject lock = new LockObject();
                synchronized (lock) {
                    locks.add(lock);
                }
            }
            try {
                Thread.sleep(100000000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
        t1.start();
        Thread.sleep(3000);
        Thread t2 = new Thread(() -> {
            // 这里循环了 40 次。达到了批量撤销的阈值
            for (int i = 0; i < 40; i++) {
                LockObject lock = locks.get(i);
                synchronized (lock) {
                }
            }
            try {
                Thread.sleep(10000000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
        t2.start();
        //———————————分割线，前面代码不再赘述——————————————————————————————————————————
        Thread.sleep(3000);
        System.out.println("打印 locks 中第11个对象的对象头：");
        System.out.println((ClassLayout.parseInstance(locks.get(10)).toPrintable()));
        System.out.println("打印 locks 中第26个对象的对象头：");
        System.out.println((ClassLayout.parseInstance(locks.get(25)).toPrintable()));
        System.out.println("打印 locks 中第90个对象的对象头：");
        System.out.println((ClassLayout.parseInstance(locks.get(89)).toPrintable()));
        Thread t3 = new Thread(() -> {
            for (int i = 20; i < 40; i++) {
                LockObject lock = locks.get(i);
                synchronized (lock) {
                    if (i == 20 || i == 22) {
                        System.out.println("thread3 第" + i + "次");
                        System.out.println((ClassLayout.parseInstance(lock).toPrintable()));
                    }
                }
            }
        });
        t3.start();
        Thread.sleep(10000);
        System.out.println("重新输出新实例 LockObject");
        System.out.println((ClassLayout.parseInstance(new LockObject()).toPrintable()));
    }
}

输出结果如图所示，前 20 个对象，没有触发批量重偏向机制，线程 t2 执行释放同步锁后，转变为无锁状态；20 至 40 个对象，触发了批量重偏向机制，对象为偏向状态，偏向线程 t2；第 41 个对象之后，没有触发批量重偏向机制，对象仍偏向线程 t1。

当线程 t3 过来竞争时，这时已经达到了批量撤销的阈值，且第 21 和 23 个对象已经进行过重偏向了，并不会再次重偏向线程 t3。此时会触发批量撤销机制，对象锁膨胀为轻量级锁。

如果 LockObject 的实例对象中，经历过批量重偏向和批量撤销情况后，后面的对象会直接在实例化后转为无锁。

7.4、结论

1、批量重偏向和批量撤销是针对类的优化，和对象无关。
2、偏向锁重偏向一次之后不可再次重偏向。
3、当某个类已经触发批量撤销机制后，JVM 会默认当前类产生了严重的问题，剥夺了该类的新实例对象使用偏向锁的权利

锁降级（不重要）

其实，只被 VMThread 访问，降级也就没啥意义了。所以可以简单认为锁降级不存在！

https://www.zhihu.com/question/63859501

参考资料

http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html