关于java:再谈synchronized锁升级

在图文详解Java对象内存布局这篇文章中，在钻研对象头时咱们理解了synchronized锁降级的过程，因为篇幅无限，对锁降级的过程介绍的比拟简略，本文在上一篇的根底上，来具体钻研一下锁降级的过程以及各个状态下锁的原理。

1 无锁

在上一篇文章中，咱们提到过 jvm会有4秒的偏差锁开启的延迟时间，在这个偏差提早内对象处于为无锁态。如果敞开偏差锁启动提早、或是通过4秒且没有线程竞争对象的锁，那么对象会进入无锁可偏差状态。

精确来说，无锁可偏差状态应该叫做匿名偏差(Anonymously biased)状态，因为这时对象的mark word中后三位曾经是101，然而threadId指针局部依然全副为0，它还没有向任何线程偏差。综上所述，对象在刚被创立时，依据jvm的配置对象可能会处于无锁或 匿名偏差 两个状态。

此外，如果在jvm的参数中敞开偏差锁，那么直到有线程获取这个锁对象之前，会始终处于无锁不可偏差状态。批改jvm启动参数：

-XX:-UseBiasedLocking

提早5s后打印对象内存布局：

public static void main(String[] args) throws InterruptedException {    User user=new User();    TimeUnit.SECONDS.sleep(5);    System.out.println(ClassLayout.parseInstance(user).toPrintable());}

能够看到，即便通过肯定的启动延时，对象始终处于001无锁不可偏差状态。大家可能会有疑难，在无锁状态下，为什么要存在一个不可偏差状态呢？通过查阅材料失去的解释是：

JVM外部的代码有很多中央也用到了synchronized，明确在这些中央存在线程的竞争，如果还须要从偏差状态再逐渐降级，会带来额定的性能损耗，所以JVM设置了一个偏差锁的启动提早，来升高性能损耗

也就是说，在无锁不可偏差状态下，如果有线程试图获取锁，那么将跳过降级偏差锁的过程，间接应用轻量级锁。应用代码进行验证：

//-XX:-UseBiasedLockingpublic static void main(String[] args) throws InterruptedException {    User user=new User();    synchronized (user){        System.out.println(ClassLayout.parseInstance(user).toPrintable());    }}

查看后果能够看到，在敞开偏差锁状况下应用synchronized，锁会间接降级为轻量级锁（00状态）:

在目前的根底上，能够用流程图概括下面的过程：

额定留神一点就是匿名偏差状态下，如果调用零碎的hashCode()办法，会使对象回到无锁态，并在markword中写入hashCode。并且在这个状态下，如果有线程尝试获取锁，会间接从无锁降级到轻量级锁，不会再降级为偏差锁。

2 偏差锁

2.1 偏差锁原理

匿名偏差状态是偏差锁的初始状态，在这个状态下第一个试图获取该对象的锁的线程，会应用CAS操作（汇编命令CMPXCHG）尝试将本人的threadID写入对象头的mark word中，使匿名偏差状态降级为已偏差（Biased）的偏差锁状态。在已偏差状态下，线程指针threadID非空，且偏差锁的工夫戳epoch为有效值。

如果之后有线程再次尝试获取锁时，须要查看mark word中存储的threadID是否与本人雷同即可，如果雷同那么示意以后线程曾经取得了对象的锁，不须要再应用CAS操作来进行加锁。

如果mark word中存储的threadID与以后线程不同，那么将执行CAS操作，试图将以后线程的ID替换mark word中的threadID。只有当对象处于上面两种状态中时，才能够执行胜利：

对象处于匿名偏差状态
对象处于可重偏差（Rebiasable）状态，新线程可应用CAS将threadID指向本人

如果对象不处于下面两个状态，阐明锁存在线程竞争，在CAS替换失败后会执行偏差锁撤销操作。偏差锁的撤销须要期待全局平安点Safe Point（平安点是 jvm为了保障在垃圾回收的过程中援用关系不会发生变化设置的平安状态，在这个状态上会暂停所有线程工作），在这个平安点会挂起取得偏差锁的线程。

在暂停线程后，会通过遍历以后jvm的所有线程的形式，查看持有偏差锁的线程状态是否存活：

如果线程还存活，且线程正在执行同步代码块中的代码，则降级为轻量级锁
如果持有偏差锁的线程未存活，或者持有偏差锁的线程未在执行同步代码块中的代码，则进行校验是否容许重偏差：
- 不容许重偏差，则撤销偏差锁，将mark word降级为轻量级锁，进行CAS竞争锁
- 容许重偏差，设置为匿名偏差锁状态，CAS将偏差锁从新指向新线程

实现下面的操作后，唤醒暂停的线程，从平安点继续执行代码。能够应用流程图总结下面的过程：

2.2 偏差锁降级

在下面的过程中，咱们曾经晓得了匿名偏差状态能够变为无锁态或降级为偏差锁，接下来看一下偏差锁的其余状态的扭转

偏差锁降级为轻量级锁

public static void main(String[] args) throws InterruptedException {    User user=new User();    synchronized (user){        System.out.println(ClassLayout.parseInstance(user).toPrintable());    }    Thread thread = new Thread(() -> {        synchronized (user) {            System.out.println("--THREAD--:"+ClassLayout.parseInstance(user).toPrintable());        }    });    thread.start();    thread.join();    System.out.println("--END--:"+ClassLayout.parseInstance(user).toPrintable());}

查看内存布局，偏差锁降级为轻量级锁，在执行实现同步代码后开释锁，变为无锁不可偏差状态：

偏差锁降级为重量级锁

public static void main(String[] args) throws InterruptedException {    User user=new User();    Thread thread = new Thread(() -> {        synchronized (user) {            System.out.println("--THREAD1--:" + ClassLayout.parseInstance(user).toPrintable());            try {                user.wait(2000);            } catch (InterruptedException e) {                e.printStackTrace();            }            System.out.println("--THREAD END--:" + ClassLayout.parseInstance(user).toPrintable());        }    });    thread.start();    thread.join();    TimeUnit.SECONDS.sleep(3);    System.out.println(ClassLayout.parseInstance(user).toPrintable());}

查看内存布局，能够看到在调用了对象的wait()办法后，间接从偏差锁升级成了重量级锁，并在锁开释后变为无锁态：

这里是因为wait()办法调用过程中依赖于重量级锁中与对象关联的monitor，在调用wait()办法后monitor会把线程变为WAITING状态，所以才会强制降级为重量级锁。除此之外，调用hashCode办法时也会使偏差锁间接降级为重量级锁。

在下面剖析的根底上，再加上咱们上一篇中讲到的轻量级锁降级到重量级锁的常识，就能够对下面的流程图进行欠缺了：

2.3 批量重偏差

在未禁用偏差锁的状况下，当一个线程建设了大量对象，并且对它们执行完同步操作解锁后，所有对象处于偏差锁状态，此时若再来另一个线程也尝试获取这些对象的锁，就会导偏差锁的批量重偏差（Bulk Rebias）。当触发批量重偏差后，第一个线程完结同步操作后的锁对象当再被同步拜访时会被重置为可重偏差状态，以便容许疾速重偏差，这样可能缩小撤销偏差锁再降级为轻量级锁的性能耗费。

首先看一下和偏差锁无关的参数，批改jvm启动参数，应用上面的命令能够在我的项目启动时打印jvm的默认参数值：

-XX:+PrintFlagsFinal

须要关注的属性有上面3个：

BiasedLockingBulkRebiasThreshold：偏差锁批量重偏差阈值，默认为20次
BiasedLockingBulkRevokeThreshold：偏差锁批量撤销阈值，默认为40次
BiasedLockingDecayTime：重置计数的延迟时间，默认值为25000毫秒（即25秒）

批量重偏差是以class而不是对象为单位的，每个class会保护一个偏差锁的撤销计数器，每当该class的对象产生偏差锁的撤销时，该计数器会加一，当这个值达到默认阈值20时，jvm就会认为这个锁对象不再适宜原线程，因而进行批量重偏差。而间隔上次批量重偏差的25秒内，如果撤销计数达到40，就会产生批量撤销，如果超过25秒，那么就会重置在[20, 40)内的计数。

下面这段实践是不是听下来有些难了解，没关系，咱们先用代码验证批量重偏差的过程：

private static Thread t1,t2;public static void main(String[] args) throws InterruptedException {          TimeUnit.SECONDS.sleep(5);    List<Object> list = new ArrayList<>();    for (int i = 0; i < 40; i++) {        list.add(new Object());    }    t1 = new Thread(() -> {        for (int i = 0; i < list.size(); i++) {            synchronized (list.get(i)) {            }        }        LockSupport.unpark(t2);    });    t2 = new Thread(() -> {        LockSupport.park();        for (int i = 0; i < 30; i++) {            Object o = list.get(i);            synchronized (o) {                if (i == 18 || i == 19) {                    System.out.println("THREAD-2 Object"+(i+1)+":"+ClassLayout.parseInstance(o).toPrintable());                }            }        }    });    t1.start();    t2.start();    t2.join();    TimeUnit.SECONDS.sleep(3);    System.out.println("Object19:"+ClassLayout.parseInstance(list.get(18)).toPrintable());    System.out.println("Object20:"+ClassLayout.parseInstance(list.get(19)).toPrintable());    System.out.println("Object30:"+ClassLayout.parseInstance(list.get(29)).toPrintable());    System.out.println("Object31:"+ClassLayout.parseInstance(list.get(30)).toPrintable());}

剖析下面的代码，当线程t1运行完结后，数组中所有对象的锁都偏差t1，而后t1唤醒被挂起的线程t2，线程t2尝试获取前30个对象的锁。咱们打印线程t2获取到的第19和第20个对象的锁状态：

线程t2在拜访前19个对象时对象的偏差锁会降级到轻量级锁，在拜访后11个对象（下标19-29）时，因为偏差锁撤销次数达到了20，会触发批量重偏差，将锁的状态变为偏差线程t2。在全副线程完结后，再次查看第19、20、30、31个对象锁的状态：

线程t2完结后，第1-19的对象开释轻量级锁变为无锁不可偏差状态，第20-30的对象状态为偏差锁、但从偏差t1改为偏差t2，第31-40的对象因为没有被线程t2拜访所以放弃偏差线程t1不变。

2.4 批量撤销

在多线程竞争强烈的情况下，应用偏差锁将会导致性能升高，因而产生了批量撤销机制，接下来应用代码进行测试：

private static Thread t1, t2, t3;public static void main(String[] args) throws InterruptedException {    TimeUnit.SECONDS.sleep(5);    List<Object> list = new ArrayList<>();    for (int i = 0; i < 40; i++) {        list.add(new Object());    }    t1 = new Thread(() -> {        for (int i = 0; i < list.size(); i++) {            synchronized (list.get(i)) {            }        }        LockSupport.unpark(t2);    });    t2 = new Thread(() -> {        LockSupport.park();        for (int i = 0; i < list.size(); i++) {            Object o = list.get(i);            synchronized (o) {                if (i == 18 || i == 19) {                    System.out.println("THREAD-2 Object"+(i+1)+":"+ClassLayout.parseInstance(o).toPrintable());                }            }        }        LockSupport.unpark(t3);    });    t3 = new Thread(() -> {        LockSupport.park();        for (int i = 0; i < list.size(); i++) {            Object o = list.get(i);            synchronized (o) {                System.out.println("THREAD-3 Object"+(i+1)+":"+ClassLayout.parseInstance(o).toPrintable());            }        }    });    t1.start();    t2.start();    t3.start();    t3.join();    System.out.println("New: "+ClassLayout.parseInstance(new Object()).toPrintable());}

对下面的运行流程进行剖析：

线程t1中，第1-40的锁对象状态变为偏差锁
线程t2中，第1-19的锁对象撤销偏差锁降级为轻量级锁，而后对第20-40的对象进行批量重偏差
线程t3中，首先间接对第1-19个对象竞争轻量级锁，而从第20个对象开始往后的对象不会再次进行批量重偏差，因而第20-39的对象进行偏差锁撤销降级为轻量级锁，这时t2和t3线程一共执行了40次的锁撤销，触发锁的批量撤销机制，对偏差锁进行撤销置为轻量级锁

看一下在3个线程都完结后创立的新对象：

能够看到，创立的新对象为无锁不可偏差状态001，阐明当类触发了批量撤销机制后，jvm会禁用该类创建对象时的可偏差性，该类新创建的对象全副为无锁不可偏差状态。

2.5 总结

偏差锁通过打消资源无竞争状况下的同步原语，进步了程序在单线程下拜访同步资源的运行性能，然而当呈现多个线程竞争时，就会撤销偏差锁、降级为轻量级锁。

如果咱们的利用零碎是高并发、并且代码中同步资源始终是被多线程拜访的，那么撤销偏差锁这一步就显得多余，偏差锁撤销时进入Safe Point产生STW的景象应该是被竭力防止的，这时应该通过禁用偏差锁来缩小性能上的损耗。

3 轻量级锁

3.1 轻量级锁原理

1、在代码拜访同步资源时，如果锁对象处于无锁不可偏差状态，jvm首先将在以后线程的栈帧中创立一条锁记录（lock record），用于寄存：

displaced mark word（置换标记字）：寄存锁对象以后的mark word的拷贝
owner指针：指向以后的锁对象的指针，在拷贝mark word阶段临时不会解决它

2、在拷贝mark word实现后，首先会挂起线程，jvm应用CAS操作尝试将对象的 mark word 中的 lock record 指针指向栈帧中的锁记录，并将锁记录中的owner指针指向锁对象的mark word

如果CAS替换胜利，示意竞争锁对象胜利，则将锁标记位设置成 00，示意对象处于轻量级锁状态，执行同步代码中的操作

如果CAS替换失败，则判断以后对象的mark word是否指向以后线程的栈帧：
- 如果是则示意以后线程曾经持有对象的锁，执行的是synchronized的锁重入过程，能够间接执行同步代码块
- 否则阐明该其余线程曾经持有了该对象的锁，如果在自旋肯定次数后仍未取得锁，那么轻量级锁须要降级为重量级锁，将锁标记位变成10，前面期待的线程将会进入阻塞状态

4、轻量级锁的开释同样应用了CAS操作，尝试将displaced mark word 替换回mark word，这时须要查看锁对象的mark word中lock record指针是否指向以后线程的锁记录：

如果替换胜利，则示意没有竞争产生，整个同步过程就实现了
如果替换失败，则示意以后锁资源存在竞争，有可能其余线程在这段时间里尝试过获取锁失败，导致本身被挂起，并批改了锁对象的mark word降级为重量级锁，最初在执行重量级锁的解锁流程后唤醒被挂起的线程

用流程图对下面的过程进行形容：

3.2 轻量级锁重入

咱们晓得，synchronized是能够锁重入的，在轻量级锁的状况下重入也是依赖于栈上的lock record实现的。以上面的代码中3次锁重入为例：

synchronized (user){    synchronized (user){        synchronized (user){            //TODO        }    }}

轻量级锁的每次重入，都会在栈中生成一个lock record，然而保留的数据不同：

首次调配的lock record，displaced mark word复制了锁对象的mark word，owner指针指向锁对象
之后重入时在栈中调配的lock record中的displaced mark word为null，只存储了指向对象的owner指针

轻量级锁中，重入的次数等于该锁对象在栈帧中lock record的数量，这个数量隐式地充当了锁重入机制的计数器。这里须要计数的起因是每次解锁都须要对应一次加锁，只有最初解锁次数等于加锁次数时，锁对象才会被真正开释。在开释锁的过程中，如果是重入则删除栈中的lock record，直到没有重入时则应用CAS替换锁对象的mark word。

3.3 轻量级锁降级

在jdk1.6以前，默认轻量级锁自旋次数是10次，如果超过这个次数或自旋线程数超过CPU核数的一半，就会降级为重量级锁。这时因为如果自旋次数过多，或过多线程进入自旋，会导致耗费过多cpu资源，重量级锁状况下线程进入期待队列能够升高cpu资源的耗费。自旋次数的值也能够通过jvm参数进行批改：

-XX:PreBlockSpin

jdk1.6当前退出了自适应自旋锁 （Adapative Self Spinning），自旋的次数不再固定，由jvm本人管制，由前一次在同一个锁上的自旋工夫及锁的拥有者的状态来决定：

对于某个锁对象，如果自旋期待刚刚胜利取得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次胜利，进而容许自旋期待继续绝对更长时间
对于某个锁对象，如果自旋很少胜利取得过锁，那在当前尝试获取这个锁时将可能省略掉自旋过程，间接阻塞线程，避免浪费处理器资源。

上面通过代码验证轻量级锁降级为重量级锁的过程：

public static void main(String[] args) throws InterruptedException {    User user = new User();    System.out.println("--MAIN--:" + ClassLayout.parseInstance(user).toPrintable());    Thread thread1 = new Thread(() -> {        synchronized (user) {            System.out.println("--THREAD1--:" + ClassLayout.parseInstance(user).toPrintable());            try {                TimeUnit.SECONDS.sleep(5);            } catch (InterruptedException e) {                e.printStackTrace();            }        }    });    Thread thread2 = new Thread(() -> {        try {            TimeUnit.SECONDS.sleep(2);        } catch (InterruptedException e) {            e.printStackTrace();        }        synchronized (user) {            System.out.println("--THREAD2--:" + ClassLayout.parseInstance(user).toPrintable());        }    });    thread1.start();    thread2.start();    thread1.join();    thread2.join();    TimeUnit.SECONDS.sleep(3);    System.out.println(ClassLayout.parseInstance(user).toPrintable());}

在下面的代码中，线程2在启动后休眠两秒后再尝试获取锁，确保线程1可能先失去锁，在此基础上造成锁对象的资源竞争。查看对象锁状态变动：

在线程1持有轻量级锁的状况下，线程2尝试获取锁，导致资源竞争，使轻量级锁降级到重量级锁。在两个线程都运行完结后，能够看到对象的状态复原为了无锁不可偏差状态，在下一次线程尝试获取锁时，会间接从轻量级锁状态开始。

下面在最初一次打印前将主线程休眠3秒的起因是锁的开释过程须要肯定的工夫，如果在线程执行实现后间接打印对象内存布局，对象可能仍处于重量级锁状态。

3.4 总结

轻量级锁与偏差锁相似，都是jdk对于多线程的优化，不同的是轻量级锁是通过CAS来防止开销较大的互斥操作，而偏差锁是在无资源竞争的状况下齐全打消同步。

轻量级锁的“轻量”是绝对于重量级锁而言的，它的性能会稍好一些。轻量级锁尝试利用CAS，在降级为重量级锁之前进行补救，目标是为了缩小多线程进入互斥，当多个线程交替执行同步块时，jvm应用轻量级锁来保障同步，防止线程切换的开销，不会造成用户态与内核态的切换。然而如果适度自旋，会引起cpu资源的节约，这种状况下轻量级锁耗费的资源可能反而会更多。

4 重量级锁

4.1 Monitor

重量级锁是依赖对象外部的monitor（监视器/管程）来实现的，而monitor 又依赖于操作系统底层的Mutex Lock（互斥锁）实现，这也就是为什么说重量级锁比拟“重”的起因了，操作系统在实现线程之间的切换时，须要从用户态切换到内核态，老本十分高。在学习重量级锁的工作原理前，首先须要理解一下monitor中的外围概念：

owner：标识领有该monitor的线程，初始时和锁被开释后都为null
cxq (ConnectionList)：竞争队列，所有竞争锁的线程都会首先被放入这个队列中
EntryList：候选者列表，当owner解锁时会将cxq队列中的线程挪动到该队列中
OnDeck：在将线程从cxq挪动到EntryList时，会指定某个线程为Ready状态（即OnDeck），表明它能够竞争锁，如果竞争胜利那么称为owner线程，如果失败则放回EntryList中
WaitSet：因为调用wait()或wait(time)办法而被阻塞的线程会被放在该队列中
count：monitor的计数器，数值加1示意以后对象的锁被一个线程获取，线程开释monitor对象时减1
recursions：线程重入次数

用图来示意线程竞争的的过程：

当线程调用wait()办法，将开释以后持有的monitor，将owner置为null，进入WaitSet汇合中期待被唤醒。当有线程调用notify()或notifyAll()办法时，也会开释持有的monitor，并唤醒WaitSet的线程从新参加monitor的竞争。

4.2 重量级锁原理

当降级为重量级锁的状况下，锁对象的mark word中的指针不再指向线程栈中的lock record，而是指向堆中与锁对象关联的monitor对象。当多个线程同时拜访同步代码时，这些线程会先尝试获取以后锁对象对应的monitor的所有权：

获取胜利，判断以后线程是不是重入，如果是重入那么recursions+1
获取失败，以后线程会被阻塞，期待其余线程解锁后被唤醒，再次竞争锁对象

在重量级锁的状况下，加解锁的过程波及到操作系统的Mutex Lock进行互斥操作，线程间的调度和线程的状态变更过程须要在用户态和外围态之间进行切换，会导致耗费大量的cpu资源，导致性能升高。

总结

在jdk1.6中，引入了偏差锁和轻量级锁，并应用锁降级机制对synchronized进行了充沛的优化。其实除锁降级外，还应用了锁打消、锁粗化等优化伎俩，所以对它的意识要脱离“重量级”这一概念，不要再单纯的认为它的性能差了。在某些场景下，synchronized的性能甚至曾经超过了Lock同步锁。

只管java对synchronized做了这些优化，然而在应用过程中，咱们还是要尽量减少锁的竞争，通过减小加锁粒度和缩小同步代码的执行工夫，来升高锁竞争，尽量使锁维持在偏差锁和轻量级锁的级别，防止降级为重量级锁，造成性能的损耗。

最初不得不再提一句，在java15中曾经默认禁用了偏差锁，并弃用所有相干的命令行选项，尽管说不确定将来的LTS版本会怎么改变，然而理解一下偏差锁的根底也没什么不好的，毕竟你发任你发，我用java8~

如果文章对您有所帮忙，欢送关注公众号 码农参上