synchronized底层原理（二）

书接上文

1. 锁升级原理

前面介绍了对象的几种加锁状态，分别是无锁、偏向锁、轻量级锁和重量级锁。有下面几个关键点：

• 当开启JVM偏向延迟时对象初始状态为无锁，若加锁后则变为轻量级锁，轻量级锁在发生锁竞争时，竞争锁的线程会通过一次CAS自旋判断能不能获取锁，如果在这个期间另一个线程释放了锁，那么锁还是轻量级锁，否则膨胀为重量级锁。
• 当关闭JVM延迟偏向时，对象初始创建为偏向状态，初始默认为不偏向任何线程，加锁后偏向指定加锁线程，如果发生偏向撤销（如调用hashcode）的情况，若对象没有被锁时偏向锁会变为无锁状态，若锁定了会变成轻量级锁，若当前对象锁定，且在同步代码块中调用hashcode方法或者wait方法会直接升级为重量级锁，注意偏向锁释放后对象不会变为无锁状态，还是会保持偏向状态。

从图中可以发现无锁状态也可以直接膨胀为重量级锁状态，这里解释一下，首先我们需要了解一下无锁状态是怎么变为轻量级锁状态的。

主要分为三个步骤：

• 首先复制mark word到displaced word（注意只有该线程第一次加轻量级锁的时候会设置displaced word，后续发生锁重入时都会设置为null）
• CAS将对象mark word的信息替换为指向现场操作数栈顶层的锁记录
• 修改mark word锁记录为00
• 将栈帧中的锁记录obj指向锁定的对象

当字节码解释器执行monitorenter字节码轻度锁住一个对象时，就会在获取锁的线程，显示或者隐式分配一个lockword。若在上面加轻量级锁时发生了激烈竞争，轻量级锁会直接膨胀为重量级锁。

2. Synchronized锁优化

1. 偏向锁批量重偏向&批量撤销

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

批量重偏向：随着时间的推移，原先获取偏向锁的线程可能会不再访问锁。为了防止这种情况下过多的线程都尝试争夺锁，Java引入了批量重偏向机制。批量重偏向是指当某个线程获取锁的时候，JVM会检查此锁的偏向状态，如果发现有一定数量（默认为20次）的线程都不再访问这个锁，那么JVM会认为这个锁不再是偏向锁，而是要进行批量重偏向，重新选取一个线程来获得锁，并更新偏向锁的线程ID。

批量撤销：是指当有很多线程都尝试获取某个锁时，JVM会判断当前的锁是否适合做为偏向锁，如果不适合，就会取消偏向状态，将锁升级为轻量级锁或重量级锁。这样可以防止偏向锁机制在高竞争的情况下带来额外的性能损失。

总结原理就是：以class为单位，为每个class维护一个偏向锁撤销计数器，每一次该class的对象发生偏向撤销操作时，该计数器+1，当这个值达到重偏向阈值(默认20)时，JVM就认为该class的偏向锁有问题，因此会进行批量重偏向。每个class对象会有一个对应的epoch字段，每个处于偏向锁状态对象的Mark Word中也有该字段，其初始值为创建该对象时class中的epoch的值。每次发生批量重偏向时，就将该值+1，同时遍历JVM中所有线程的栈，找到该class所有正处于加锁状态的偏向锁，将其epoch字段改为新值。下次获得锁时，发现当前对象的epoch值和class的epoch不相等，那就算当前已经偏向了其他线程，也不会执行撤销操作，而是直接通过CAS操作将其Mark Word的Thread Id 改成当前线程Id。当达到重偏向阈值(默认20)后，假设该class计数器继续增长，当其达到批量撤销的阈值后 (默认40)，JVM就认为该class的使用场景存在多线程竞争，会标记该class为不可偏向，之后， 对于该class的锁，直接走轻量级锁的逻辑。批量重偏向(bulk rebias)机制是为了解决:一个线程创建了大量对象并执行了初始的同步操作，后来另一个线程也来将这些对象作为锁对象进行操作，这样会导致大量的偏向锁撤销操作。 批量撤销(bulk revoke)机制是为了解决:在明显多线程竞争剧烈的场景下使用偏向锁是不合适的。下面代码演示一下：

public class Main {
    public static void main(String[] args) throws InterruptedException {
        //偏向锁延迟
        Thread.sleep(5000);
        //用来存放锁对象
        List<Object> jack=new ArrayList<>();
        new Thread(()->{
            for (int i = 0; i < 50; i++) {
                //创建锁对象并添加的集合中
                Object obj=new Object();
                //保持可见性
                synchronized (obj){
                    jack.add(obj);
                }

            }
            try {
                //保持线程t1存活
                Thread.sleep(100000);
            }catch (Exception e){
                e.printStackTrace();
            }
        },"t1").start();
        //保证对象创建完成
        Thread.sleep(3000);
        System.out.println("对象的初始对象头："+ClassLayout.parseInstance(jack.get(19)).toPrintable());
        new Thread(()->{
            for (int i = 0; i < 40; i++) {
                Object obj=jack.get(i);
                synchronized (obj){
                    if(i>=15 && i<=21||i>=38){
                        System.out.println("线程t2第"+(i+1)+"次加锁：" + ClassLayout.parseInstance(obj).toPrintable());
                    }
                }
                if(i==17 || i==19){
                    System.out.println("线程t2第"+(i+1)+"次释放锁：" + ClassLayout.parseInstance(obj).toPrintable());
                }

            }

        },"t2").start();
    }
}

我们来分析一下输出结果：

首先初始状态对象偏向线程t1

16次加锁时为轻量级锁

第17次加锁时为轻量级锁，17次解锁为无锁状态

18次加锁此时就是发生了重偏向变回了偏向锁，后面的结果都会是所有对象的偏向锁偏向了新的线程（不知道为什么不是阈值20）

下面再来测试批量撤销
当撤销偏向锁阈值超过 40 次后，jvm 会认为不该偏向，于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的。 注意:时间-XX:BiasedLockingDecayTime=25000ms范围内没有达到40次，撤销次数清为0， 重新计时

发现所有的50次都在做偏向锁撤销

新创建的对象直接变为无锁状态

上面的现象可以总结为三点：

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

2. 自旋优化

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

• 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
• 在 Java 6 之后自旋是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次;反之，就少自旋甚至不自旋，比较智能。
• Java 7 之后不能控制是否开启自旋功能，使用-XX:PreBlockSpin参数来设置自旋锁等待次数

注意:自旋的目的是为了减少线程挂起的次数，尽量避免直接挂起线程(挂起操作涉及系统调用，存在用户态和内核态切换，这才是重量级锁最大的开销)

3. 锁粗化

假设一系列的连续操作都会对同一个对象反复加锁及解锁，甚至加锁操作是出现在循环体中的，即使没有出现线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。如果JVM检测到有一连串零碎的操作都是对同一对象的加锁，将会扩大加锁同步的范围(即锁粗化)到整个操作序列的外部。

StringBuffer buffer=new StringBuffer(); /**
*锁粗化
*/
public void append(){
 buffer.append("aaa").append(" bbb").append(" ccc");
}

append源码如下：

 public synchronized StringBuffer append(CharSequence s) {
        toStringCache = null;
        super.append(s);
        return this;
    }

可以发现它是同步方法，所以向上面那个append方法连续加aaa，bbb和ccc三个字符串，是需要多长加锁解锁的。如果JVM检测到有一连串的对同一个对象加锁和解锁的操作，就会将其合并成一次范围更大的加锁和解锁操作，即在第一次 append方法时进行加锁，最后一次append方法结束后进行解锁。

4. 锁消除

锁消除即删除不必要的加锁操作。锁消除是Java虚拟机在JIT编译期间，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过锁消除，可以节省毫无意义的请求锁时间。

public class LockEliminationTest{
  /**
  *锁消除
  * ‐XX:+EliminateLocks 开启锁消除(jdk8默认开启)
  * ‐XX:‐EliminateLocks 关闭锁消除
  * @param str1
  * @param str2
  */
  public void append(String str1, String str2) {
  StringBuffer stringBuffer = new StringBuffer();
  stringBuffer.append(str1).append(str2);
  }
 
  public static void main(String[] args) throws InterruptedException {
  LockEliminationTest demo = new LockEliminationTest();
  long start = System.currentTimeMillis();
  for (int i = 0; i < 100000000; i++) {
 	 demo.append("aaa", "bbb")
}
long end = System.currentTimeMillis(); System.out.println("执行时间:" + (end ‐ start) + " ms"); }
}

StringBuffer的append是个同步方法，但是append方法中的 StringBuffer 属于一个局部变量，不可能从该方法中逃逸出去，因此其实这过程是线程安全的，可以将锁消除。(这里就涉及一个逃逸分析（这里是JIT优化的内容）的概念）