并发关键字：Synchronized底层实现，锁升级原理

原创已于 2026-05-12 20:27:01 修改 · 505 阅读

4 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#java #开发语言 #后端

于 2022-02-18 11:33:21 首次发布

并发专栏收录该内容

34 篇文章

订阅专栏

本文详细讲解了synchronized的使用方式，包括修饰实例方法、静态方法和代码块，并剖析了其原理。重点介绍了锁对象的存在位置、锁升级机制（包括偏向锁和轻量级锁）及其优缺点。此外，还探讨了正确使用synchronized的实践和避免常见错误。

在这里插入图片描述

synchronized使用方式

我们知道并发编程会产生各种问题的源头是可见性，原子性，有序性。

而synchronized能同时保证可见性，原子性，有序性。所以我们在解决并发问题的时候经常用synchronized，当然还有很多其他工具，如volatile。但是volatile只能保证可见性，有序性，不能保证原子性

synchronized可以用在如下地方

修饰实例方法，对当前实例对象this加锁
修饰静态方法，对当前类的Class对象加锁
修饰代码块，指定加锁对象，对给定对象加锁

修饰实例方法

public class SynchronizedDemo {
    
    public synchronized void methodOne() {
    
    }
}

修饰静态方法

public class SynchronizedDemo {

    public static synchronized void methodTwo() {

    }
}

修饰代码块

public class SynchronizedDemo {

    public void methodThree() {
    	// 对当前实例对象this加锁
        synchronized (this) {
        
        }
    }

    public void methodFour() {
    	// 对class对象加锁
        synchronized (SynchronizedDemo.class) {
        
        }
    }
}

synchronized实现原理

Java对象组成

我们都知道对象是放在堆内存中的，对象大致可以分为三个部分，分别是对象头，实例变量和填充字节

在这里插入图片描述

对象头，主要包括两部分 Mark Word （标记字段），Klass Pointer（类型指针）。

Mark Word：用于存储对象自身的运行时数据，hashcode，gc 分代年龄，锁状态，偏向线程id

Klass Point ：指向对象类型元数据的指针
实例变量，存放类的属性数据信息，包括父类的属性信息，这部分内存按4字节对齐
填充数据，由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐

假如有如下的类，a=100这个信息就存储在实例变量中

public class Test {
    int a = 100;
}

填充数据主要是为了方便内存管理，如你想要10字节的内存，但是会给你分配16字节的内存，多出来的字节就是填充数据

synchronized不论是修饰方法还是代码块，都是通过持有修饰对象的锁来实现同步，那么synchronized锁对象是存在哪里的呢？答案是存在锁对象的对象头Mark Word，来看一下Mark Word存储了哪些内容？

由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间，也就是说，Mark Word会随着程序的运行发生变化，变化状态如下 (32位虚拟机)：

在这里插入图片描述
这里我们主要分析一下重量级锁也就是通常说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的），省略部分属性

ObjectMonitor() {
    _count        = 0; //记录数
    _recursions   = 0; //锁的重入次数
    _owner        = NULL; //指向持有ObjectMonitor对象的线程 
    _WaitSet      = NULL; //调用wait后，线程会被加入到_WaitSet
    _EntryList    = NULL ; //等待获取锁的线程，会被加入到该列表
}

在这里插入图片描述

结合线程状态解释一下执行过程。(状态装换参考自《深入理解Java虚拟机》)

新建（New），新建后尚未启动的线程
运行（Runable），Runnable包括了操作系统线程状态中的Running和Ready
无限期等待（Waiting），不会被分配CPU执行时间，要等待被其他线程显式的唤醒。例如调用没有设置Timeout参数的Object.wait()方法
限期等待（Timed Waiting），不会被分配CPU执行时间，不过无需等待其他线程显示的唤醒，在一定时间之后会由系统自动唤醒。例如调用Thread.sleep()方法
阻塞（Blocked），线程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等待获取着一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生，而“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态
结束（Terminated）：线程结束执行

在这里插入图片描述

对于一个synchronized修饰的方法(代码块)来说：

当多个线程同时访问该方法，那么这些线程会先被放进_EntryList队列，此时线程处于blocked状态
当一个线程获取到了对象的monitor后，那么就可以进入running状态，执行方法，此时，ObjectMonitor对象的/_owner指向当前线程，_count加1表示当前对象锁被一个线程获取
当running状态的线程调用wait()方法，那么当前线程释放monitor对象，进入waiting状态，ObjectMonitor对象的/_owner变为null，_count减1，同时线程进入_WaitSet队列，直到有线程调用notify()方法唤醒该线程，则该线程进入_EntryList队列，竞争到锁再进入_Owner区
如果当前线程执行完毕，那么也释放monitor对象，ObjectMonitor对象的/_owner变为null，_count减1

由此看来，monitor对象存在于每个Java对象的对象头中(存储的是指针)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于顶级对象Object中的原因

synchronized如何获取monitor对象？

那么synchronized是通过什么方式来获取monitor对象的？

synchronized修饰代码块

public class SyncCodeBlock {
    public int count = 0;
    public void addOne() {
        synchronized (this) {
            count++;
        }
    }
}

javac SyncCodeBlock.java
javap -v SyncCodeBlock.class

反编译的字节码如下

  public void addOne();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=3, args_size=1
         0: aload_0
         1: dup
         2: astore_1
         3: monitorenter // 进入同步方法
         4: aload_0
         5: dup
         6: getfield      #2                  // Field count:I
         9: iconst_1
        10: iadd
        11: putfield      #2                  // Field count:I
        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:

可以看到进入同步代码块，执行monitorenter指令，退出同步代码块，执行monitorexit指令，可以看到有2个monitorexit指令，第一个是正常退出执行的，第二个是当异常发生时执行的

synchronized修饰方法

public class SyncMethod {
    public int count = 0;
    public synchronized void addOne() {
        count++;
    }
}

反编译的字节码如下

  public synchronized void addOne();
    descriptor: ()V
    // 方法标识ACC_PUBLIC代表public修饰，ACC_SYNCHRONIZED指明该方法为同步方法
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=3, locals=1, args_size=1
         0: aload_0
         1: dup
         2: getfield      #2                  // Field count:I
         5: iconst_1
         6: iadd
         7: putfield      #2                  // Field count:I
        10: return
      LineNumberTable:

我们并没有看到monitorenter和monitorexit指令，那是怎么来实现同步的呢？
可以看到方法被标识为ACC_SYNCHRONIZED，表明这是一个同步方法

锁的升级

jdk1.6前只有重量级锁，会有用户态->内核态切换的开销

jdk1.6后引入锁升级机制（无锁->偏向锁->轻量级锁->重量级锁）

jdk1.6之前的synchronized到底有多慢？

我们假设执行下面的代码用的是jdk1.5，来看看会发生什么。
假设doSomeThing执行1000次，才有可能发生一次并发执行。但是每次都需要让操作系统从用户态转换到核心态，太耗时了。

public class RunTest {
    
    public synchronized void doSomeThing() {
        
    }
}

然后Doug Lea看不下去了（你用的并发包就是他写的），写了ReentrantLock类，效率比synchronized快多了，为了理解让大家理解ReentrantLock到底快在哪？我仿造ReentrantLock写一个实现

public class MyLockV1 {

    private final AtomicBoolean locked = new AtomicBoolean(false);
    private final Queue<Thread> waiters = new ConcurrentLinkedQueue<>();

    public void lock() {
        Thread current = Thread.currentThread();
        waiters.add(current);

        while (waiters.peek() != current || !locked.compareAndSet(false, true)) {
            LockSupport.park(this);
        }

        waiters.remove();
    }

    public void unLock() {
        locked.set(false);
        LockSupport.unpark(waiters.peek());
    }
}

可以看到在api层面就已经解决并发问题，加锁没有竞争的时候一个cas就搞定了，节省了大量时间

Doug Lea一个类的效率都比synchronized的效率高，估计synchronized的开发人员看了都不好意思了，于是对synchronized进行了一系列改造，即我们常说的锁升级过程。

synchronized锁有四种状态，无锁，偏向锁，轻量级锁，重量级锁，这几个状态会随着竞争状态逐渐升级，锁可以升级但不能降级

为什么要引入偏向锁？

因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。

为什么要引入轻量级锁？

轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态，代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋这等待锁释放。

锁升级的过程

无锁

对象刚创建时，Mark Word 中锁标志位 = 01（无锁状态）
没有线程竞争

偏向锁

场景：同一线程多次进入同步块
实现：将当前线程 ID 写入 Mark Word（锁标志位仍为 01）
好处：后续同一线程重入时，只检查线程 ID，无需 CAS
撤销：当另一个线程尝试获取锁时，需要撤销偏向锁（可能升级为轻量级锁）

轻量级锁（自旋锁）

场景：两个线程交替执行，或短暂竞争
实现：

线程在自己的栈帧中创建 Lock Record
用 CAS 尝试将对象的 Mark Word 复制到 Lock Record，并指向自己
成功 → 获得轻量级锁
失败 → 自旋重试（1.6 后自适应自旋）

好处：避免用户态到内核态切换

cas时，旧值只能是锁没有被其他线程占有的状态

重量级锁

场景：多个线程长时间并发竞争
触发条件：

自旋超过一定次数
有更多线程来竞争时

实现：

升级为重量级锁（锁标志位 = 10）
指向一个 monitor 对象（基于操作系统 mutex）
未竞争到的线程进入阻塞队列（内核态）

几种锁的优缺点

在这里插入图片描述

用锁的最佳实践

错误的加锁姿势1

synchronized (new Object())

每次调用创建的是不同的锁，相当于无锁

错误的加锁姿势2

private Integer count;
synchronized (count)

String，Boolean在实现了都用了享元模式，即值在一定范围内，对象是同一个。所以看似是用了不同的对象，其实用的是同一个对象。会导致一个锁被多个地方使用

正确的加锁姿势

// 普通对象锁
private final Object lock = new Object();
// 静态对象锁
private static final Object lock = new Object();

题外话

ConcurrentHashMap在jdk1.7的时候，实现用的是分段锁，用ReentrantLock来保证并发安全。

而在jdk1.8的时候，抛弃了原有的分段锁，而采用了 CAS + synchronized 来保证并发安全性，也可以说明synchronized的的效率现在确实很高了。

参考博客

好文
[0]https://blog.csdn.net/tongdanping/article/details/79647337
[1]https://blog.csdn.net/javazejian/article/details/72828483
[2]https://www.cnblogs.com/grow001/p/12232708.html?utm_source=gold_browser_extension
[3]https://blog.csdn.net/chenssy/article/details/54883355
lock接口方法简介
[4]https://zhuanlan.zhihu.com/p/38264728
condition的使用
[5]https://www.cnblogs.com/xrq730/p/4855155.html
线程状态
[6]https://blog.csdn.net/xiaosheng900523/article/details/82964768