synchronized锁升级过程

为什么要进行锁升级

锁升级其实就是对synchronized的优化，以前用synchronized修饰一个对象或者是方法，方法也等于是锁住对象，直接上一把操作系统层面的大锁，万一只有少量线程的话会大题小作了，如果大量线程的话又会特别消耗时间，划不来，所以要将以前的二话不说上一把大锁进行优化。
锁升级的过程是 无锁 --> 偏向锁 --> 轻量级锁 --> 重量级锁

锁升级预备知识之对象头

对象在jvm中是这么布局的，分为三块，分别是对象头、实例数据和对齐填充。
我们要学习锁升级就要先学习对象头，因为锁的升级过程就是在对象头里标志的。
由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间。

锁标志位	状态
01	无锁或者偏向锁
00	轻量级锁
10	重量级锁
11	GC标记

根据上图和状态表可知，无锁状态也就是对象刚被new出来的时候，对象有HashCode区域，同时锁标志位为01，注意在对象未使用到HashCode的时候是0。偏向锁状态拥有线程ID和Epoch区域且锁标志位为01。轻量级锁有指向轻量级锁的指针且标志位为00。重量级锁有指向重量级锁的指针以及锁标志位为10。

锁升级预备知识之CAS

CAS全程叫做Compare And Set，比较并设置，简单的来说就是把对象当前的值拿来跟这个线程操作之前的值进行比较，如果一样说明在该线程操作期间没有其他线程对对象进行操作，所以就可以把该线程操作之后的值设置给对象，如果比较结果是不一样的说明在该线程操作期间有其他线程动了对象，那么该线程就会把操作之前的值修改为对象当前的值之后再进行操作。循环进行一直到成功设置值为止，所以它也叫做自旋锁。

ABA问题

假设线程1和线程2都对x进行操作，x的值为1，那么如果线程2在自旋的过程中线程1对x进行了加0的操作或者除以1的操作，那么x的值还是1，但是线程1还是对x进行了操作的，那么线程2不知道哇，1和它原来的值是一样的，但是x已经不是原来的那个x了，这就是ABA问题。
那么如何解决ABA问题呢？加版本号。例如，每次有线程修改了引用的值，就会进行版本的更新，虽然两个线程持有相同的引用，但他们的版本不同，这样，我们就可以预防 ABA 问题了。

锁升级详细过程

一开始对象被创建，这个对象的状态是无锁状态，当有一个线程过来锁它的时候，这个对象会贴上这个线程的ID，Epoch是转换成这个偏向锁的时间戳。然后如果没有其他线程要来锁这个对象，这个对象的对象头就会一直贴着之前的线程的ID，当然如果从头到尾都没有第二个线程的话，也就是编译器检测到了程序中只有一个线程，会有一个锁消除的优化机制。但是如果有第二个线程过来争夺这个对象了，锁就会升级成轻量级锁。
轻量级锁也就是进行CAS操作的自旋锁，在代码进入同步块的时候，如果对象还没有被锁定也就是状态位为 01，那么jvm首先会在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用来存储对象当前的MarkWord的拷贝。

官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word。

然后jvm进行CAS操作尝试将对象的MarkWord更新为指向锁记录的指针。如果更新成功，那么这个线程就拥有了该对象的锁，并且对象的MarkWord标志位转变为 00，即表示此对象处于轻量级锁定状态；如果更新失败，虚拟机首先会检查对象的MarkWord是否指向当前线程的栈帧，如果指向则说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块中执行了，否则说明这个锁对象已经被其他线程占有了，就继续CAS，默认自旋超过10次线程就会被挂起，这个次数可以改，因为线程一直自旋也是很消耗资源的。如果有两条以上的线程竞争同一个锁，那轻量级锁不再有效，要膨胀为重量级锁，锁标志变为 10，MarkWord中存储的就是指向重量级锁的指针，而后面等待的线程也要进入阻塞状态。
synchronized的重量级锁是通过对象内部的一个叫做监视器锁（monitor）来实现的，监视器锁本质又是依赖于底层的操作系统的Mutex Lock（互斥锁）来实现的。而操作系统实现线程之间的切换需要从用户态转换到核心态，这个时间成本会非常高。

以上就是我对synchronized锁升级过程的学习了，如有错误，欢迎指正！