作者：
可爱猪猪-帅锅一枚
作者的网名很阔爱，如果喜欢本文章一定要点 喜欢 或者 打赏，拜托~
作者一直在进步，需要你们的支持和鼓励，谢谢!
人生理想：在程序猿界混出点名堂！
背景
synchronized在jdk1.6以前性能比较差，建议使用ReentryLock来替换，然后在jdk1.6开始，对synchronized进行了优化，所以经常有人说性能已经不是二者做出选择的一个考虑因素。
为什么在JDK1.6以前synchronized性能低呢？
因为synchronized是有点重（先暂时说有点重，其实它是重量级锁），对性能大的影响是阻塞的是实现，挂起 线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来了很大的压力。
那JDK1.6如何优化的呢？
其实思路很简单，大概思路就是
- 如果一个线程在使用锁的时候或者即使多个线程，但之间并不存在竞争关系，比如A线程用完锁，B线程再用，这个时候只是在锁上加了一个标识，不需要资源消耗。其实这就是偏向锁。
2.当A线程和B线程同时竞争一把锁的时候，通过CAS来获取锁，也就是线程并不多，但是同一时候有了竞争，这时候就是一个轻量级锁。
3.然后竞争太激烈了，转入到内核态来完成，这个就是重量级锁。
因此在不同的锁状态下，使用不同的锁，而大部分锁并达不到重量级锁，因此性能较优。
来看看具体是怎么实现的
对象头
java的对象头由以下三部分组成：
1，Mark Word
2，指向类的指针
3，数组长度（只有数组对象才有）
Mark Word
Mark Word记录了对象和锁有关的信息，当这个对象被synchronized关键字当成同步锁时，围绕这个锁的一系列操作都和Mark Word有关。
Mark Word在32位JVM中的长度是32bit，在64位JVM中长度是64bit。
Mark Word在不同的锁状态下存储的内容不同，在32位JVM中是这么存的：
Mark Word.jpg
其中无锁和偏向锁的锁标志位都是01，只是在前面的1bit区分了这是无锁状态还是偏向锁状态。
JDK1.6以后的版本在处理同步锁时存在锁升级的概念，JVM对于同步锁的处理是从偏向锁开始的，随着竞争越来越激烈，处理方式从偏向锁升级到轻量级锁，最终升级到重量级锁。
JVM一般是这样使用锁和Mark Word的：
1，当没有被当成锁时，这就是一个普通的对象，Mark Word记录对象的HashCode，锁标志位是01，是否偏向锁那一位是0。
2，当对象被当做同步锁并有一个线程A抢到了锁时，锁标志位还是01，但是否偏向锁那一位改成1，前23bit记录抢到锁的线程id，表示进入偏向锁状态。
3，当线程A再次试图来获得锁时，JVM发现同步锁对象的标志位是01，是否偏向锁是1，也就是偏向状态，Mark Word中记录的线程id就是线程A自己的id，表示线程A已经获得了这个偏向锁，可以执行同步锁的代码。
4，当线程B试图获得这个锁时，JVM发现同步锁处于偏向状态，但是Mark Word中的线程id记录的不是B，那么线程B会先用CAS操作试图获得锁，这里的获得锁操作是有可能成功的，因为线程A一般不会自动释放偏向锁。如果抢锁成功，就把Mark Word里的线程id改为线程B的id，代表线程B获得了这个偏向锁，可以执行同步锁代码。如果抢锁失败，则继续执行步骤5。
5，偏向锁状态抢锁失败，代表当前锁有一定的竞争，偏向锁将升级为轻量级锁。JVM会在当前线程的线程栈中开辟一块单独的空间，里面保存指向对象锁Mark Word的指针，同时在对象锁Mark Word中保存指向这片空间的指针。上述两个保存操作都是CAS操作，如果保存成功，代表线程抢到了同步锁，就把Mark Word中的锁标志位改成00，可以执行同步锁代码。如果保存失败，表示抢锁失败，竞争太激烈，继续执行步骤6。
6，轻量级锁抢锁失败，JVM会使用自旋锁，自旋锁不是一个锁状态，只是代表不断的重试，尝试抢锁。从JDK1.7开始，自旋锁默认启用，自旋次数由JVM决定。如果抢锁成功则执行同步锁代码，如果失败则继续执行步骤7。
7，自旋锁重试之后如果抢锁依然失败，同步锁会升级至重量级锁，锁标志位改为10。在这个状态下，未抢到锁的线程都会被阻塞。
作者：lkforce
来源：CSDN
原文：https://blog.csdn.net/lkforce/article/details/81128115
版权声明：本文为博主原创文章，转载请附上博文链接！
可参考两篇文章来具体学习（按顺序来看）：
https://blog.csdn.net/lkforce/article/details/81128115
https://blog.csdn.net/sifanchao/article/details/84144141
网友评论