synchronized已经不在臃肿了，放下对他的成见之初识轻量级锁

本文主要是介绍synchronized已经不在臃肿了，放下对他的成见之初识轻量级锁，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

物竞天择，适者生存。JDK也在不断的优化中。关于JDK中synchronized锁内部也是不断的优化，前面我们分析了偏向锁用来解决初期问题，随着争抢的不断堆积轻量级锁营运而生。
关注我，一个不断进步的社畜码农，带你一起摆脱危机

轻量级锁

上面说了没有竞争情况并且开启偏向锁的同时，才会产生偏向锁。但是偏向锁是不会主动撤销的。我们看下下面案列
vm配置如下-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0

 public class SimpleTest {public static void main(String[] args) {SimpleTest test = new SimpleTest();System.out.println(ClassLayout.parseInstance(test).toPrintable());synchronized (test) {System.out.println("hello world");System.out.println(ClassLayout.parseInstance(test).toPrintable());}System.out.println("锁释放后："+ClassLayout.parseInstance(test).toPrintable());}}

我们能够看到上锁前，上锁中，上锁后三个过程test对象中的markword一直都是偏向锁。这说明不会主动撤销

基于这个前提下，我们试想下有两个线程不同时间针对同一个对象上锁，这叫不叫资源竞争？因为不在同一时间运行期间实际上是交互进行的，但是因为偏向锁默认条件下是不会主动释放的。在偏向锁上锁流程是通过CAS将当前线程写入markword的，在写入之前是会进行对比锁对象markword是否是当前线程的。如果是和当前线程id一致的话，只会在计数器上加1 ，用于实现可重入式锁。
如果是第二个线程不管是不是同时都会发生线程id不一致情况。这个时候就会发生偏向锁升级成轻量级锁。这个升级的过程也是很麻烦的过程。JVM实际上需要找到安全点(即线程不活动时间点)先撤销偏向锁，然后在上轻量级锁

偏向锁图示

轻量级锁图示

通过图示我们也能够看的出来，偏向锁只会发生一次CAS，而轻量级锁会无时无刻不发生CAS ，我们要知道CAS引发的线程自旋也是耗费CPU调度的，因为线程都处于活跃状态，那么CPU就会发生线程调度切换。所以在并发不是很高和普遍的项目中偏向锁是很搞笑的。

 class User{String userName;}public class SoftLock {public static void main(String[] args) throws InterruptedException {User user = new User();System.out.println("加锁前(禁用偏向延迟，此时应该是偏向锁默认)："+ClassLayout.parseInstance(user).toPrintable());final Thread t1 = new Thread(new Runnable() {@Overridepublic void run() {synchronized (user) {System.out.println("t1加锁中：" + ClassLayout.parseInstance(user).toPrintable());}}});t1.start();t1.join();final Thread t2 = new Thread(new Runnable() {@Overridepublic void run() {synchronized (user) {System.out.println("t1加锁中,因为t1加锁后线程偏向锁不会释放，所以t2会发生偏向锁撤销，最终t2轻量级锁：" + ClassLayout.parseInstance(user).toPrintable());}}});t2.start();t2.join();System.out.println("加锁后(无锁)："+ClassLayout.parseInstance(user).toPrintable());}}

上述代码我们能够看出，在t2线程中尝试加锁就会变成轻量级锁。轻量级锁和偏向锁不同的是，轻量级锁使用后会释放锁，变成无锁状态
当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。
在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，然后拷贝对象头中的Mark Word复制到锁记录中。
拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock Record里的owner指针指向对象的Mark Word。
如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，表示此对象处于轻量级锁定状态。
如果轻量级锁的更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明多个线程竞争锁。
若当前只有一个等待线程，则该线程通过自旋进行等待。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。
多个线程在不同的时间段请求同一把锁，也就是说没有锁竞争。针对这种情形，Java 虚拟机采用了轻量级锁，来避免重量级锁的阻塞以及唤醒
轻量级锁的条件是发生竞争或者是不得不上轻量级锁。下面我们看一种不得不上轻量级锁的案列，注意VM属性开启偏向锁延迟及VM不做任何配置

 public class SimpleTest {public static void main(String[] args) {SimpleTest test = new SimpleTest();System.out.println(ClassLayout.parseInstance(test).toPrintable());synchronized (test) {System.out.println(ClassLayout.parseInstance(test).toPrintable());}}}

这段代码和上面偏向锁演示匿名偏向锁的代码是一样的，不同的是VM的配置取消了。也就是开启了偏向锁延迟。那么我们第一次打印的test对象中markword中是无锁状态。按理说第二次就应该上偏向锁了。但是我们试想一下在第二次上偏向锁的时候延迟偏向也有可能会上偏向锁，这不就发生了资源争抢了吗，为了避免和延迟偏向发生冲突，所以第二次直接是轻量级锁。