java架构之路（多线程）synchronized详解以及锁的膨胀升级过程

synchronized的使用

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

我们先来看一段简单的代码

public class SynchronizedTest {

private static Object object = new Object();

public static void main(String[] args) {

synchronized (object){

System.out.println(“只有我拿到锁啦”);

}

}

}

就这样synchronized就可以使用了，这样是每次去拿全局对象的object去锁住后续的代码段。我们来看一下汇编指令码

public static void main(java.lang.String[]);

Code:

0: getstatic #2 // Field object:Ljava/lang/Object;

3: dup

4: astore_1

5: monitorenter

6: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;

9: ldc #4 // String 只有我拿到锁啦

11: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V

14: aload_1

15: monitorexit

16: goto 24

19: astore_2

20: aload_1

21: monitorexit

22: aload_2

23: athrow

24: return

Exception table:

from to target type

6 16 19 any

19 22 19 any

明显看到了两个很重要的方法monitorenter和monitorexit两个方法，也就是说我们的synchronized方法加锁是基于monitorenter加锁和monitorexit解锁来操作的

我们得知是由monitorenter来控制加锁和monitorexit解锁的，我们完全可以这样来操作。上次我们说过一个unsafe类。

public class SynchronizedTest {

private static Object obj = new Object();

public void lockMethod(){

UnsafeInstance.reflectGetUnsafe().monitorEnter(obj);

}

public void unLockMethod(){

UnsafeInstance.reflectGetUnsafe().monitorExit(obj);

}

}

就是我们上次说的unsafe那个类给我们提供了加锁和解锁的方法，这样就是实现夸方法的加锁和解锁了，但是超级不建议这样的使用，后面的AQS回去说别的方式。越过虚拟机直接操作底层的，我们一般是不建议这样来做的。

我们还可以将synchronized锁放置在方法上。例如

public class SynchronizedTest {

private static Object object = new Object();

public static synchronized void lockMethod() {

System.out.println(“只有我拿到锁啦”);

}

}

这样加锁是加在了this当前类对象上的。如果不加static，锁是加在类对象上的，需要注意我们用的spring的bean作用域

并且我们的synchronized是一个可重入锁，在jvm源码中有一个数值来记录加锁和解锁的次数，所以我们是可以多次套用synchronized的

public void lockMethod(){

synchronized(obj){

synchronized(obj){

System.out.println(“我没报错”);

}

}

}

synchronized到底锁了什么

还是拿上个每次加锁的时候会在对象头内记录我们的加锁信息，我们这里来说一下对象头里面都放置了什么吧。

以32位JVM内部存储结构为例

由此看出对象一直是有一个位置来记录我们的锁信息的。说到这我们就可以来看一下我们锁的膨胀升级过程了。

锁的膨胀升级

我们说过了对象头的内容，接下来可以说说我们的锁内部是如何升级上锁的了。从无锁到重量级锁的一个升级过程，我们来边画图，边详细看一下。

无锁状态：

开始时应该这样的，线程A和线程B要去争抢锁对象，但还未开始争抢，锁对象的对象头是无锁的状态也就是25bit位存的hashCode，4bit位存的对象的分代年龄，1bit位记录是否为偏向锁，2bit位记录状态，优先看最后2bit位，是01，所以说我们的对象可能无锁或者偏向锁状态的，继续前移一个位置，有1bit专门记录是否为偏向锁的，1代表是偏向锁，0代表无锁，刚刚开始的时候一定是一个无锁的状态，这个不需要多做解释，系统不同内部bit位存的东西可能有略微差异，但关键信息是一致的。

偏向锁：

这时线程开始占有锁对象，比如线程A得到了锁对象。

就会变成这样的，线程A拿到锁对象，将我们的偏向锁标志位改为1，并且将原有的hashCode的位置变为23bit位存放线程A的线程ID（用CAS算法得到的线程A的ID），2bit位存epoch，偏向锁是永远不会被释放的。

接下来，线程B也开始运行，线程B也希望得到这把锁啊，于是线程B会检查23bit位存的是不是自己的线程ID，因为被线程A已经持有了，一定锁的23bit位一定不是线程B的线程ID了

然后线程B也会不甘示弱啊，会尝试修改一次23bit位的对象头存储，如果说这时恰好线程A释放了锁，可以修改成功，然后线程B就可以持有该偏向锁了。如果修改失败，开始升级锁。自己无法修改，线程B只能找“大哥”了，线程B会通知虚拟机撤销偏向锁，然后虚拟机会撤销偏向锁，并告知线程A到达安全点进行等待。线程A到达了安全点，会再次判断线程是否已经退出了同步块，如果退出了，将23bit位置空，这时锁不需要升级，线程B可以直接进行使用了，还是将23bit的null改为线程B的线程ID就可以了。

轻量级锁：