浅析synchronized锁升级的原理与实现 1

水w

已于 2024-09-01 15:32:53 修改

阅读量621

点赞数 18

分类专栏： java 文章标签： java juc 锁机制 synchronized

于 2024-09-01 15:30:33 首次发布

本文链接：https://blog.csdn.net/qq_45956730/article/details/141784374

版权

java 专栏收录该内容

46 篇文章 8 订阅

订阅专栏

背景

在多线程编程中，线程同步是一个关键的概念，它确保了多个线程对共享资源的安全访问。Java中的synchronized关键字是一种常用的线程同步机制，它不仅提供了互斥访问的功能，还具备锁升级的特性。本文将深入探讨synchronized的锁升级原理和实现方式。

在jdk1.5（包含）版本之前，因为加锁和释放锁的过程JVM的底层都是由操作系统mutex lock来实现的，其中会涉及上下文的切换（即用户态和内核态的转换），性能消耗极其高，所以在当时synchronized锁是公认的重量级锁。

后来JVM开发团队为解决性能问题，在jdk1.5版本中加入了JUC并发包，包下开发了很多Lock相关的锁，来解决同步的性能问题，同时也开始在后续的迭代版本中对synchronized锁不断的进行优化来提高性能，比如在jdk1.6版本中就引入了“偏向锁”和“轻量级锁”，通过锁的升级来解决不同并发场景下的性能问题。

通常使用synchronized方式加锁影响性能，主要原因如下：

加锁解锁依赖JVM层的的额外操作完成。
重量级锁是通过操作系统对线程的挂起和恢复来实现，涉及内核态和用户态的切换

锁的用法

synchronized是java的同步关键字，可以使共享资源串行的执行，避免多线程竞争导致的执行结果错误，使用方法有以下三种。

作用在类的普通方法（非静态方法）上，锁的是当前对象实例。
作用在类的静态方法上，锁的是当前类class。
作用在代码块上，锁的是指定的对象实例。

public synchronized void lockInstance() {
    System.out.println("锁的是当前对象实例");
}

public synchronized static void lockClass() {
    System.out.println("锁的是当前类class");
}

public void lockObject(Object obj) {
    synchronized (obj) {
        System.out.println("锁的是指定的对象实例obj");
    }
}

底层实现

synchronized在代码层的用法有三种，锁对象实例、锁类class、锁指定实例对象，我们可以将以下代码编译成class后，在反编译出来看看JVM指令码是怎样的。

public class Synchronized1 {
    public static void main(String[] args) {
        System.out.println("test Synchronized1");
    }
    public synchronized void lockInstance() {
        System.out.println("锁的是当前对象实例");
    }
 
    public synchronized static void lockClass() {
        System.out.println("锁的是当前类class");
    }
 
    public void lockObject(Object obj) {
        synchronized (obj) {
            System.out.println("锁的是指定的对象实例obj");
        }
    }
}

通过javap命令反编译class文件，

javap -c -v -l Synchronized1.class

我们主要关注那3个方法的JVM指令码。

我们可以发现，在方法（非静态方法锁的是对象，静态方法锁的是类class）上加synchronized关键字，是通过在access_flags中设置ACC_SYNCHRONIZED标志来实现，而synchronized使用在代码块上，是通过monitorenter和monitorexit指令来实现。

重量锁底层最终是依靠操作系统的阻塞和唤醒来实现，每个对象有一个监视器锁（monitor），在 Java 虚拟机(HotSpot)中，monitor 是基于 C++的ObjectMonitor实现，对象锁里有计数器、重入次数、等待锁的线程列表、存储该monitor的对象、拥有monitor的线程等参数。

虚拟机是通过进入和退出monitor来实现同步，monitorenter指令是在编译后插入到同步代码块的开始位置，monitorexit是插入到方法结束处和异常处。

根据虚拟机规范的要求，

在执行monitorenter指令时，首先要去尝试获取对象的锁，
如果这个对象没被锁定，或者当前线程已经拥有了那个对象的锁，把锁的计数器加1。相应地，在执行monitorexit指令时会将锁计数器减1，当计数器被减到0时，锁就释放了（注意执行monitorexit的线程必须是已经获得monitor对象锁的线程）。
如果获取对象锁失败了，那当前线程就要阻塞等待，直到对象锁被另一个线程释放然后由操作系统唤醒等到锁的线程继续竞争锁直到获取到锁为止。

原理分析

通过以上的用法，我们可以看到synchronized使用起来很简单，那它究竟是怎么做到线程间互斥访问的呢，底层原理及实现是怎样的呢，接下来我们一一解答。

java对象的内存布局里面有一个对象头Markword，在synchronized锁的使用过程中就用到了，如下图所示。

锁的状态

在jdk1.5版本（包含）之前，锁的状态只有两种状态：“无锁状态”和“重量级锁状态”，只要有线程访问共享资源对象，则锁直接成为重量级锁，jdk1.6版本后，对synchronized锁进行了优化，新加了“偏向锁”和“轻量级锁”，用来减少上下文的切换以提高性能，所以锁就有了4种状态。

1）无锁

对于共享资源，不涉及多线程的竞争访问。

2）偏向锁

共享资源首次被访问时，JVM会对该共享资源对象做一些设置，比如将对象头中是否偏向锁标志位置为1，对象头中的线程ID设置为当前线程ID（注意：这里是操作系统的线程ID），后续当前线程再次访问这个共享资源时，会根据偏向锁标识跟线程ID进行比对是否相同，比对成功则直接获取到锁，进入临界区域（就是被锁保护，线程间只能串行访问的代码），这也是synchronized锁的可重入功能。

3）轻量级锁

当多个线程同时申请共享资源锁的访问时，这就产生了竞争，JVM会先尝试使用轻量级锁，以CAS方式来获取锁（一般就是自旋加锁，不阻塞线程采用循环等待的方式），成功则获取到锁，状态为轻量级锁，失败（达到一定的自旋次数还未成功）则锁升级到重量级锁。

4）重量级锁

如果共享资源锁已经被某个线程持有，此时是偏向锁状态，未释放锁前，再有其他线程来竞争时，则会升级到重量级锁，另外轻量级锁状态多线程竞争锁时，也会升级到重量级锁，重量级锁由操作系统来实现，所以性能消耗相对较高。

这4种级别的锁，在获取时性能消耗：重量级锁 > 轻量级锁 > 偏向锁 > 无锁。

锁升级

锁升级是针对于synchronized锁在不同竞争条件下的一种优化，根据锁在多线程中竞争的程度和状态，synchronized锁可在无锁、偏向锁、轻量级锁和重量级锁之间进行流转，以降低获取锁的成本，提高获取锁的性能。

通过下面这个命令，可以看到所有JVM参数的默认值。

java -XX:+PrintFlagsFinal -version

锁升级过程

1）当JVM启动后，一个共享资源对象直到有线程第一个访问时，这段时间内是处于无锁状态，对象头的Markword里偏向锁标识位是0，锁标识位是01。

2）从jdk1.6之后，JVM有两个默认参数是开启的，

-XX:+UseBiasedLocking：表示启用偏向锁
- 想要关闭偏向锁，可添加JVM参数：-XX:-UseBiasedLocking。
-XX:BiasedLockingStartupDelay=4000：表示JVM启动4秒后打开偏向锁，也可以自定义这个延迟时间。
- 如果设置成0，那么JVM启动就打开偏向锁。

当一个共享资源首次被某个线程访问时，锁就会从无锁状态升级到偏向锁状态，偏向锁会在Markword的偏向线程ID里存储当前线程的操作系统线程ID，偏向锁标识位是1，锁标识位是01。此后如果当前线程再次进入临界区域时，只比较这个偏向线程ID即可，这种情况是在只有一个线程访问的情况下，不再需要操作系统的重量级锁来切换上下文，提供程序的访问效率。

另外需要注意的是，由于硬件资源的不断升级，获取锁的成本随之下降，jdk15版本后默认关闭了偏向锁。

如果未开启偏向锁（或者在JVM偏向锁延迟时间之前）有线程访问共享资源则直接由无锁升级为轻量级锁，请看第3步。

3）如果未开启偏向锁（或者在JVM偏向锁延迟时间之前），有线程访问共享资源则直接由无锁升级为轻量级锁，开启偏向线程锁后，并且当前共享资源锁已经是偏向锁时，再有第二个线程访问共享资源锁时，此时锁可能升级为轻量级锁，也可能还是偏向锁状态，因为这取决于线程间的竞争情况，

如果没有竞争，那么偏向锁的效率更高（因为频繁的锁竞争会导致偏向锁的撤销和升级到轻量级锁），继续保持偏向锁。
如果有竞争，则锁状态会从偏向锁升级到轻量级锁，这种情况下轻量级锁效率会更高。

4）当轻量级锁获取锁失败时，说明有竞争存在，轻量级锁会升级为重量级锁，此时，JVM会将线程阻塞，直到获取到锁后才能进入临界区域，底层是通过操作系统的mutex lock来实现的，每个对象指向一个monitor对象，这个monitor对象在堆中与锁是关联的，通过monitorenter指令插入到同步代码块在编译后的开始位置，monitorexit指令插入到同步代码块的结束处和异常处，这两个指令配对出现。

JVM的线程和操作系统的线程是对应的，重量级锁的Markword里存储的指针是这个monitor对象的地址，操作系统来控制内核态中的线程的阻塞和恢复，从而达到JVM线程的阻塞和恢复，涉及内核态和用户态的切换，影响性能，所以叫重量级锁。