synchronized 锁升级(锁膨胀)机制 线程之间的爱恨纠葛

synchronized 简介

synchronized是Java的关键字，可用来给对象和方法或者代码块加锁，当它锁定一个方法或者一个代码块的时候，同一时刻最多只有一个线程执行这段代码。Java1.6之前是悲观锁也就是现在的重量级锁，开销非常大，1.6之后JVM引入了偏向锁和轻量级锁，采用了现在的锁升级机制，使得性能有了很大的提高。

相信大家多少在项目中也用到过这个关键字处理并发问题，今天话不多说，来看看它是怎么通过锁升级怎么处理线程间的纠葛的。

Java对象头中的Mark Word

先引入一个概念，Mark Word：Java对象头里的Mark Word里默认的存放的对象的Hashcode,分代年龄和锁标记位。32位的JVM Mark Word默认存储结构为：

synchronized 锁升级过程中一直伴随MarkWord字段的变化，我们可以结合锁升级的过程来理解锁升级的机制。

synchronized 锁升级

我们都知道锁的4种状态：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态（级别从低到高）

假设有一个被synchronized修饰的对象、调用该对象的线程A、线程B，从实例里面分别实现这几种锁状态：

1.无锁状态

没有线程持有synchronized修饰的对象的时候，是无锁状态。
25bit位存的是对象的hashCode，4bit存分代年龄，1bit是是否为偏向锁，0表示无锁，最后2bit为锁标志位，01表示此时是无锁或者偏向锁状态，
此时，线程A开始占有锁对象，对象为无锁状态，线程A得到了锁对象。

这个时候锁对象由无锁状态变成偏向锁。
MarkWord偏向锁标志位就会变成1，并且将原来存放HashCode的位置用23bit存放线程A的线程ID（CAS算法算出），2bit位epoch，偏向锁是永远不会被释放的。

2.偏向锁状态

在线程A持有锁对象且是偏向锁的情况下，线程B开始运行，也希望得到这个锁对象，于是会检查23bit位中是否存的线程B的线程ID,显然这时锁对象存的是线程A的ID。

然而线程B并不想轻易放弃，会尝试修改一次23bit位的对象头存储，如果这个时候线程A释放了锁，可以修改成功，然后B线程就可以持有该偏向锁了。
但是此时因为线程A如果没有释放锁，线程B自己无法修改对象头，只能通知虚拟机撤销偏向锁，然后虚拟机会各校偏向锁，并且告知线程A达到安全点进行等待，线程A到达了安全点，会判断线程是否已经退出了同步块，如果退出了，会把23bit位置null，这个时候锁不需要升级，线程B可以直接使用了，所以线程B还是把23bit的null换成自己的线程ID就可以了。
但是我们讨论锁升级的话肯定不能让线程B轻易得逞，此时线程A还是没退出同步块，线程B修改失败了，这个时候线程A持有的偏向锁就会升级成为轻量级锁。

3.轻量级锁状态

此时线程B没有拿到锁，我们已经升级到轻量级锁，首先会在线程A和线程B都开辟一块LockRecord空间，然后把锁对象复制一份到自己的LockRecord空间下，并且开辟一块owner空间留作执行锁使用。

并且锁对象的前30bit位合并，等待线程A和线程B来修改指向自己的线程，假如线程A修改成功，则锁对象头的前30bit位会存线程A的LockRecord的内存地址，并且线程A的owner也会存一份锁对象的内存地址，形成一个双向指向的形式。而线程B修改失败，则进入一个自旋状态，持续来尝试修改锁对象。

但是说程B多次自旋以后还是迟迟没有拿到锁，轻量级就会升级成重量级锁。

4.重量级锁状态

如果说线程B多次自旋之后还是没有拿到锁，他会继续上告，告知虚拟机，我多次自旋还是没有拿到锁，这个时候我们的线程B就会从用户态切换到内核态，申请一个互斥量，并且将锁对象的前30bit这指向申请到的互斥量地址，并且进入睡眠状态。

然后当线程A继续运行直到完成时，当线程A想要释放锁资源的时候，发现原来的30bit位没有指向自己了，此时线程A就会释放锁，取唤醒前30bit位中互斥量对应的睡眠状态的线程，线程B唤醒后尝试获取对象锁。