写在开头
面试官：小伙子，多线程中锁用过吗？ 我：那是自然！ 面试官：那你知道synchronized的优化吗？ 我：synchronized作为重锁，开销大，在早期不被推荐使用，后期进行了优化，至于怎么优化的话，您让我想想哈... 面试官：好的，那你出去好好想吧！
对于synchronized的优化，虽然被问到的场景不多，但在很多网友发的面经中发现很多人都会挂在这个点上。
在我们初学锁时，很多人可能都觉得它是一个重量级锁，代码中不建议使用，但其实现如今经过了层层优化后，synchronized被广泛的应用在了JVM源码以及众多开源框架中，我们今天就来一起学习一下synchronized的优化过程！
对象锁的四种状态
首先，我们这里要记住一个Java迭代版本JDK1.6，这个版本对于synchronized来说是划时代的，在此之前，synchronized确实是一种重量级悲观锁，这个时候的它使用起来极耗资源，为所有高效开发者所弊病，但在1.6版本之后，引入了"偏向锁"和"轻量级锁" 的概念，这极大减少了获取synchronized锁和释放锁所需资源，synchronized重获新生！
在此之后，对象的锁便拥有了4种状态，根据锁的级别从低到高可分为：
无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁
无锁
无锁其实很好理解，就是没有对共享资源进行任何锁定，所有线程都可以去访问并修改同一资源，但同时只能有一个线程修改成功，其他线程不断尝试直至成功，并会将原内容覆盖。
偏向锁
偏向锁，指的就是偏向第一个加锁线程，对象的代码一直被同一线程执行，不存在多个线程竞争，该线程在后续的执行中自动获取锁，降低获取锁带来的性能开销。
轻量级锁
轻量级锁是指当锁是偏向锁的时候，被第二个线程 B 所访问，此时偏向锁就会升级为轻量级锁，线程 B 会通过自旋的形式尝试获取锁，线程不会阻塞，从而提高性能。
重量级锁
指当有一个线程获取锁之后，其余所有等待获取该锁的线程都会处于阻塞状态。
重量级锁通过对象内部的监视器（monitor）实现，而其中 monitor 的本质是依赖于底层操作系统的 Mutex Lock 实现，操作系统实现线程之间的切换需要从用户态切换到内核态，切换成本非常高。所以在没有被优化之前，synchronized这种重量级锁，才不受重视！
对象锁的存储
学习完对象锁的四种状态后，我们继续思考下一个问题，既然对象锁有四种状态，那它们是存储在哪里的呢？
会联想的同学，我想已经猜出了大概，首先在Java中的锁都是基于对象的，既然基于对象，那它存在的地方大概率要在对象中，而我们知道在JVM中，对象分为三个部分对象头、实例数据、字节对齐，其中对象头又由Mark Word和Klass Point构成，而Mark Word（标记字段）用于存储对象自身的运行时数据，例如存储对象的HashCode，分代年龄、锁标志位等信息，是synchronized实现轻量级锁和偏向锁的关键。我们64位虚拟机为例看下图：
当对象状态是偏向锁时，MarkWord中存储了偏向线程的ID，并且将是否偏向标志置为1；当对象状态是轻量级锁时，Mark Word存储的是指向线程栈中Lock Record的指针；当状态为重量级锁时，Mark Word为指向monitor（监视器）对象的指针。
synchronized 锁升级的过程
有了上面的知识储备，我们趁着打铁，来聊一聊synchronized 锁升级的过程，由低到高，逐渐升级。
1️⃣首先，在锁对象的对象头里面有一个 threadid 字段，未访问时 threadid 为空，这时是无锁状态，任何线程都可竞争获取共享资源；
2️⃣ 先得到共享资源的线程，其线程ID会被记录到Mark Word中，此时锁状态为偏向锁；
3️⃣ 当后续还有线程去获取共享资源时，会先判断 threadid 是否与其线程id一致。如果一致则可以直接使用此对象；如果不一致，则升级偏向锁为轻量级锁，通过自旋循环一定次数来获取锁；
4️⃣自旋的线程在自旋过程中，成功获得资源(即之前获的资源的线程执行完成并释放了共享资源)，则整个状态依然处于 轻量级锁的状态，如果自旋失败；
5️⃣进入重量级锁的状态，这个时候，自旋的线程进行阻塞，等待之前线程执行完成并唤醒自己。
结尾彩蛋
如果本篇博客对您有一定的帮助，大家记得留言+点赞+收藏呀。原创不易，转载请联系Build哥！
如果您想与Build哥的关系更近一步，还可以关注"JavaBuild888"，在这里除了看到《Java成长计划》系列博文，还有提升工作效率的小笔记、读书心得、大厂面经、人生感悟等等，欢迎您的加入！
