一文带你认知不一样的Synchronized

2024-03-29 18:34:34

上一篇文章我们花了很大的篇幅来分析理解volatile关键字，讲完volatile，当然离不开谈谈synchronized，在并发编程中，这个关键字一直都是元老级别的存在，我们习惯于称之为重量级锁，但随着Java SE 1.6版本后，Java团队对synchronized做了彻底的优化，让它具有了可轻可重，可咸可甜（乱说的）的能力。跟随我的视野，让我们来看看这到底是个啥！

一、灵魂拷问

进入正题之前，依然是俗套的灵魂拷问，你准备好了吗？

什么是synchronized，它是如何使用的？
synchronized 实现对象锁的两种方式以及它的原理？
谈谈synchronized 锁升级过程？
synchronized与volatile的区别？

不知道有没有难到你，下面就由石头我带大家由浅入深的分析这项技术。

二、基本应用

2.1 加锁方法

synchronized有三种加锁方式，包括修饰静态方法、修饰实例方法、修饰代码块，不同的加锁方式影响锁的控制粒度，需要根据实际工程环境决定。

静态方法，作用于当前类对象，即加锁的粒度是类对象本身，进入该静态方法需获取到类对象的锁。
实例方法，作用于当前类的实例，即加锁的粒度是类的实例，进入该实例方法需获取到类实例的锁。
代码块，作用于指定锁对象，即加锁的粒度是指定的锁对象，进入该代码块需获取到指定对象的锁。

2.2 代码应用

public class SyncExample {
    
    private static final Object LOCK = new Object();

    private static int i = 1;

    public synchronized static void increase1(){
        i++;
    }

    public synchronized void increase2(){
        i++;
    }

    public void increase3(){
        synchronized (LOCK){
            i++;
        }
    }
}

#increase1方法表示的是修饰静态方法；#increase2方法表示的是修饰实例方法；#increase1方法表示的是修饰代码块。

三、锁存储布局

synchronized始终与对象关联。如果方法是静态的，那么关联的对象就是类；如果该方法是非静态的，则关联的对象是实例。如果是代码块，那么就是指定的对象。很显然，锁是记录于对象中。那么问题来了，synchronized的锁具体指的是什么呢？简单理解锁就是一个共享的资源，记录了谁占有它，当前状态是什么等等。我们先来分析对象在内存中是如何存储的。

在Hotspot JVM 中，Java Object对象在内存中存储中的存储布局分为三个区域，分别是对象头、示例数据、对象填充。如图所示，数组和对象的存储布局十分相似，只是对象的头部大于数组的长度，因为数组需要存储自身的长度，为4Byte。

从图上可以看出，对象头部包括两部分，分别是对象标记和类元信息（类型指针）。对象标记，也就是Markword存储对象的 hashCode、 GC 信息和锁等信息。类元信息存储“类对象信息的指针”。在32位的 JVM 中，对象头占用8个byte，另外在64位的 JVM 占用16个字节。

如上图所示，这个是Markword类在32位的 JVM 的各种情况存储布局，Markword 里面存储的数据会随着锁标志位的变为而变化，大致存储的变化共分为五种情况。我们可以从图上看到从无锁->偏向锁->轻量级锁->重量级锁存储的变化过程，这个就是锁升级的过程。

那么问题来了，是不是所有的对象都能实现锁呢？答案是肯定的。

首先我们对于Java有一个共有的认知，那就是所以的对象都派生自Object，每个Object在内存中存储都如我们图上所示的，都有对象头，对象头中有Markword对象标记。需要注意的是，对象存储包括Markword对象标记的实现都是native的，都是C++语言实现的对象。
线程在获取锁时，实际获取的是一个监视器（monitor）对象,这是一个同步对象，所有的Java Object都包含这个对象。同样的，这个对象也是native的。

四、锁升级

Java 1.6之前，synchronized是标准的重量级锁，多个线程竞争共享资源时，未竞争到资源的线程会一直处于阻塞状态，性能开销很大，同时对于重量级锁，对于加锁和释放锁也有很多的资源消耗。为了减少性能开销，提升效率，人们针对不同的加锁场景，细分了四种锁状态，包括无锁、偏向锁、轻量级锁，重量级锁，锁的状态会根据线程竞争资源的激烈程度从低到高不断升级。

4.1 偏向锁

很多时候，锁总是被同一线程多次获取，并没有线程竞争锁。对于这样的情况，偏向锁就很适用，那到底什么时候偏向锁呢？在第三章节，我们列出了在synchronized不同的锁状态下，Markword内存布局有很大的差异。

4.1.1 偏向锁获取

当一个线程去访问synchronized关键字修饰的代码块或方法时，会在Markword中存储当前线程的ID，当再有线程想尝试进入同步块时，会先通过CAS比较当前Markword存储的线程ID是否为尝试进入同步块的线程ID，如果相等，不需要再次获取锁了，可直接执行同步代码块；如果不相等，说明当前偏向锁是偏向于其它线程，需要撤销偏向锁，然后将锁升级成轻量级锁。

4.1.2 偏向锁撤销

撤销偏向锁并不是将锁真正的撤销，成为无锁的状态。对于偏向锁的撤销，对原持有的线程和锁本身有两种情况。

如果原持有线程刚好执行完了，退出同步代码块，那么这个时候会把Markword保存的线程ID设置为空。
如果原持有线程仍在同步代码块中执行，这个时候偏向锁会升级为轻量级锁，然后原有线程继续执行。

下面图演示在synchronized修饰的同步代码块下，线程T1和线程T2先后竞争锁资源的流程。

4.2 轻量级锁

上一小节说到了两个线程竞争锁，导致偏向锁的撤销，撤销过程中有一种常见的锁升级，即升级成轻量级锁。轻量级锁适用于两个线程竞争锁资源，并且同步代码块执行很快的场景。那在对象中的Markword存储布局有变化成什么呢？

4.2.1 轻量级升级过程

众所周知，在JVM中，栈是线程私有的。升级成轻量级锁的第一步是在栈的栈帧中搞事情。

栈帧新创建锁记录LockRecord，记录中包括displaced hdr 和owner。
将锁对象头中的Markword内容复制到刚创建的栈帧中LockRecord。
将锁记录LockRecord中的owner指向锁对象。
最后将对象头的Markword中的指向栈中锁记录的指针指向锁记录LockRecord（这个步骤才是Markword存储内容真正的变化）。

变化过程如下图所示。

4.2.2 轻量级竞争过程

当一个线程占有轻量级锁时，当另一个线程来竞争时，这个线程会在原地空循环等待，而不是将线程状态转变为Blocked阻塞态。当占有的线程离开同步块，释放锁以后，另外一个线程就会迅速的获取到锁。

那么为什么未获取到锁资源的线程是循环等待，而不是阻塞呢？ 这其中最重要的原因是线程的阻塞和唤醒需要CPU从用户态转为内核态，频繁的阻塞和唤醒对CPU来说是一件负担相当重的工作，势必会给操作系统的并发性能带来非常大的压力。所以采取了循环去等待，这就是自旋锁，这种方式在AQS锁底层也用到了。

那么未获取到锁资源的线程是如何循环等待的呢? 不停的循环会消耗CPU性能，这种自旋锁当然是有停止条件的，分为两种情况。

在Java 1.6 之前，设定了一个自旋的次数，超过循环次数就会循环就会终止，一般设置的次数是10，可以通过设置HotSpot 参数 -XX:PreBlockSpin来修改，修改这个参数之前需通先通过设置参数-XX:+UseSpining开启自旋锁。
在Java 1.6 之后，引入了相较于智能的自适应自旋锁，这种方式是根据前一次在同样的锁自选的时间和锁的状态决定锁的自选时间，而不是固定自旋次数。

4.2.3 自旋锁锁释放

当未获取到锁资源的线程，自旋获取锁失败了，此时会将锁升级成重量级锁，并修改锁对象头的Markword中的值，修改的内容大致为指向重量级锁的指针和修改锁标志位为10。此时线程处于阻塞的状态。

当占有锁的退出同步代码块时，会通过CAS将栈中存储记录的Markword内容和当前锁对象Markword比较然后设值，因为当前Markword内容已经变化了，肯定会设值失败，此时线程会释放锁，释放监视器（monitor）并唤醒等待的线程。然后另一个被阻塞的线程被唤醒，重新竞争锁资源。

4.3 重量级锁

上一小节讲到了两个线程竞争锁资源，未获取到锁资源的线程在自旋策略范围内未获取到锁资源，轻量级锁就会升级成重量级锁，这个重量级就是真正的锁，它是一个互斥锁，加锁和解除锁资源都非常消耗资源。那么这个锁到底在哪儿，具体是什么样的呢？

4.3.1 锁在哪儿

当锁升级成重量级锁后，最明显的变化是锁对象的Markword的锁标记变为10，指向的内容变为指向一个监视器对象Monitor。这个监视器对象是如何实现互斥锁的呢？我们写一段代码来验证一下。

public class SyncExample {
    private static int i = 1;
    public synchronized static void increase1() {
        i++;
    }
    public static void main(String[] args) {
        synchronized (SyncExample.class){

        }
        SyncExample.increase1();
    }
}

我们先将java文件编译成SyncExample.class，然后通过javap -v SyncExample.class 指令反编译指定的Java字节码文件。

 public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=3, args_size=1
         0: ldc           #3                  // class me/stone/training/platform/training/java/thread/SyncExample
         2: dup
         3: astore_1
         4: monitorenter
         5: aload_1
         6: monitorexit
         7: goto          15
        10: astore_2
        11: aload_1
        12: monitorexit
        13: aload_2
        14: athrow
        15: invokestatic  #4                  // Method increase1:()V
        18: return

我们可以明显看到，在同步代码块中，在字节码中多了monitorenter和monitorexit，这两条指令很是关键。

monitorenter表示去获取一个监视器对象monitor，获取成功后其它竞争的线程只能进入等待队列，处于阻塞状态。
monitorexit表示释放监视器对象monitor的所有权，让其它阻塞的线程可以尝试去获取这个监视器对象。

4.3.2 Monitor 对象

synchronized修饰同步块，多线程竞争资源时，实则竞争的是一个锁对象，这个锁对象是一个Object对象，在内存中存储中包含一个对象，对象头有指向一个Markword，当锁升级成重量级锁时，Markword会指向一个Monitor对象，这个对象实际上是native的，在JVM Hotspot中，这个对象从本质上来说是一个C++ 对象，是一个ObjectMonitor类的实例。

如上图所示，Monitor有四个重要的属性。

_count，计数器。用来计数获取锁的次数，我们常说synchronized是可重入锁，这就是实现的关键。
_owner，记录当前锁持有者的线程，也就是当前谁占有这把锁。
_waitSet，wait 队列，顾名思义，当线程调用对象的wait方法后，线程会释放资源，进入该队列等待被唤醒。
_EntrySet，entry队列，这个队列就是竞争锁失败的线程排队的地方，这些线程处于阻塞态。

线程在重量级锁的竞争中获取到了锁，此时_owner指向当前线程，_count 计数加1，未获取到锁的线程进入entry队列中进行排队。如果获取到锁资源的线程再次进入同一个锁资源控制的同步块，因为判断_owner指向的是自己，所以_count加1，实现了可重入锁。最后依次退出同步块，将计数逐步减去1，最后减为0，退出所有的同步块，释放锁资源，通知entry队列可以安排队列中的线程竞争锁资源了。

wait队列很特殊，线程在持有锁的过程中执行了#wait方法，线程将释放锁对象，进入此队列。后续一直等待#notify方法唤醒，唤醒后再进入wait队列中与其他线程一起竞争锁资源。

需要注意的是，#notify方法是随机取一个wait队列中的线程放到entry队列,#notifyAll是将所有等待的线程放到entry队列。

4.3.3 不是公平锁

synchronized 重量级锁不是一个公平锁，也就是说当占有资源的线程释放掉锁资源的时候，放在entry队列的线程会同步竞争锁资源，不会让等待的最久的线程直接获取到锁，而且甚至有可能突然有一个新的线程尝试获取锁时，占有锁资源的线程恰好释放掉锁，这个新的线程会获取到锁资源。非公平锁的缺点是可能有些线程长期获取不到锁资源，处于饥饿的状态，如果要想使用公平锁，可以使用ReentrantLock的公平锁模式。

五、对比volatile

前面文章详细介绍了volatile关键字的用法，原理。这篇文章我们来总结一下这synchronized和volatile的主要区别。synchronized用于实现一个基于锁的线程模型；而volatile包括Atomic是非锁定的，这意味着线程不需要锁来访问共享变量。

synchronized	volatile
只是适用于块或方法	只是适用于变量
它基于的是锁的线程模型	借助于硬件，加上非阻塞的算法，是非锁定的
由于锁的是获取和释放，与volatile相比，性能相对较低	与synchronized相比，性能相对较高
由于是基于锁，可能会带来并发的风险，比如死锁、活锁	由于它是非锁定的，它不会受到死锁、活锁等并发风险

总的来说，volatile 不能控制线程对其对象的访问，这允许多个线程对其操作，而不需要等待对象的锁定，所以它性能相当的快，它将确保对变量的任何更改都将被刷新到主内存，然而，访问主存被认为是非常昂贵的，因此直接对主存进行读写的开销是非常大的。

synchronized 它保证一段代码一次不会被多个线程访问，消除了所有可能的竞争条件，因为是基于锁，使用它是非常昂贵的，它在一定程度上牺牲了多线程并发的优势--速度。

那么怎么使用这两个关键字呢？除了被使用的不同代码地方，还有下面两个原则。

当变量将被多个线程读取，单只是被一个线程写入时，使用volatile。
当多个线程读取和写入变量时使用synchronized。

六、总结

整篇文章就到此结束了，文章开头提到的问题，是不是自己也能回答出来了。我尽量写的细一点，但肯定还是一些非常底层的原理没有讲到，希望读者能在评论留言，一起探讨探讨。多线程下一篇讲AQS应用和实现原理。

作者：青Cheng序员石头
链接：https://juejin.cn/post/6983896198256001038
来源：掘金

码农公寓