其他分享
首页 > 其他分享> > 一文带你认知不一样的Synchronized

一文带你认知不一样的Synchronized

作者：互联网

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

一、灵魂拷问

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

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

二、基本应用

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。

Java Object.png

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

markword.png

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

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

四、锁升级

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

4.1 偏向锁

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

4.1.1 偏向锁获取

image.png

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

4.1.2 偏向锁撤销

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

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

未命名文件.png

4.2 轻量级锁

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

4.2.1 轻量级升级过程

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

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

变化过程如下图所示。

未命名文件.png

4.2.2 轻量级竞争过程

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

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

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

4.2.3 自旋锁锁释放

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

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

偏向锁升级流程图 (1).png

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，这两条指令很是关键。

4.3.2 Monitor 对象

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

未命名文件.png

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

线程在重量级锁的竞争中获取到了锁，此时_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是非锁定的，这意味着线程不需要锁来访问共享变量。

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

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

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

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

六、总结

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

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

标签：Synchronized,存储,一文,synchronized,对象,认知,获取,Markword,线程
来源： https://blog.csdn.net/GYHYCX/article/details/118699106