并发编程 - 深入理解 synchronized

在 Java 并发编程中，synchronized 是保障线程安全的核心关键字。它提供了一种简单有效的机制来实现互斥访问共享资源。然而，理解其底层原理、工作方式以及最佳实践对于编写高效、健壮的并发程序至关重要。

synchronized 的本质：监视器锁（Monitor Lock）

Java 中的 synchronized 基于 监视器锁（Monitor） 实现。每个 Java 对象都隐式关联着一个监视器锁（也称为内部锁或对象锁）。

当线程进入 synchronized 保护的代码块或方法时，它会尝试获取该对象的监视器锁，成功获取后，其他试图获取同一锁的线程将被阻塞，直到持有锁的线程释放它。

锁的获取与释放规则

进入同步块/方法前：获取锁（lock）
退出同步块/方法后：释放锁（unlock） - 包括正常退出或异常退出

synchronized 的使用方式

synchronized 的锁是基于对象实现的。

static：此时使用的是当前类.class作为锁（类锁）
非static：此时使用的是当前对象做为锁（对象锁）

主要的三种实现方式：

实例方法同步

java
public synchronized void addToCounter() {
    count++; // 锁对象是当前实例(this)
}

静态方法同步

java
public static synchronized void staticMethod() {
    // 锁对象是类的Class对象（MyClass.class）
}

同步代码块（最灵活）

java
public void updateSharedResource() {
    // ... 非同步代码
    synchronized (lockObject) { // 显式指定锁对象
        // 临界区代码
    }
    // ... 非同步代码
}

注意

多个线程必须竞争同一个锁对象才能实现互斥。

深入 JVM：synchronized 的底层实现

在了解 synchronized 的底层实现以前，要先对Java中对象在堆内存的存储有一个了解。

字节码层面

同步代码块：使用 monitorenter 和 monitorexit 指令（显式对应代码块边界）。
同步方法：方法访问标志位 ACC_SYNCHRONIZED（隐式在方法调用和返回时处理锁）。

synchronized 关键字经过Javac编译，会在同步块的前后分别形成 monitorenter 和 monitorexit 这两个字节码指令，其他试图获取同一锁的线程将被阻塞，直到持有锁的线程释放它。

对象头与 Mark Word

Java 对象在堆内存中的布局包含 对象头。

对象头中的 Mark Word 是实现锁的核心部分（存储哈希码、GC 分代年龄、锁状态标志、指向锁记录的指针、偏向线程 ID 等）。

锁的状态信息（无锁、偏向锁、轻量级锁、重量级锁）就记录在 Mark Word 中。

锁的可重入性

同一线程可多次获取同一个锁（锁计数递增），**在执行 monitorenter 指令时，首先要去尝试获取对象的锁。如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行 monitorexit 指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。

锁优化：性能优化之路（JDK 6+）

在JDK1.5的时候，Doug Lee推出了ReentrantLock，lock的性能远高于synchronized，所以JDK团队就在JDK1.6中，对synchronized做了大量的优化。

自旋锁与自适应自旋

前面我们讨论互斥同步的时候，提到了互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给Java虚拟机的并发性能带来了很大的压力。

同时，虚拟机的开发团队也注意到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂和恢复线程并不值得。现在绝大多数的个人电脑和服务器都是多路（核）处理器系统，如果物理机器有一个以上的处理器或者处理器核心，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。

自旋锁

为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

自旋等待不能代替阻塞，且先不说对处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的，所以如果锁被占用的时间很短，自旋等待的效果就会非常好，反之如果锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有价值的工作，这就会带来性能的浪费。

因此自旋等待的时间必须有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程。自旋次数的默认值是十次，用户也可以使用参数-XX：PreBlockSpin来自行更改

自适应自旋锁

无论是默认值还是用户指定的自旋次数，对整个Java虚拟机中所有的锁来说都是相同的。

在JDK 6中对自旋锁的优化，引入了自适应的自旋。自适应意味着自旋的时间不再是固定的了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而允许自旋等待持续相对更长的时间，比如持续100次忙循环。另一方面，如果对于某个锁，自旋很少成功获得过锁，那在以后要获取这个锁时将有可能直接省略掉自旋过程，以避免浪费处理器资源。

锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须再进行。

代码示例：

java
public String concatString(String s1, String s2, String s3) { 
    StringBuffer sb = new StringBuffer(); 
    sb.append(s1); 
    sb.append(s2); 
    sb.append(s3);
    return sb.toString(); 
}

每个StringBuffer.append()方法中都有一个同步块，锁就是sb对象。

虚拟机观察变量sb，经过逃逸分析后会发现它的动态作用域被限制在concatString()方法内部。也就是sb的所有引用都永远不会逃逸到concatString()方法之外，其他线程无法访问到它，所以这里虽然有锁，但是可以被安全地消除掉。在解释执行时这里仍然会加锁，但在经过服务端编译器的即时编译之后，这段代码就会忽略所有的同步措施而直接执行

通俗点来说，一个方法中，对于多个同步块，锁的都是一个StringBuffer对象，线程并发下，调用方法都会创建一个StringBuffer对象，不会存在并发安全问题，编译器即时编译后就会将方法内的同步锁消除

锁粗化

原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变少，即使存在锁竞争，等待锁的线程也能尽可能快地拿到锁。

大多数情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体之中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。

如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，以上面代码清单为例，就是扩展到第一个append()操作之前直至最后一个append()操作之后，这样只需要加锁一次就可以了。

轻量级锁

轻量级锁是JDK 6时加入的新型锁机制，它名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就被称为“重量级”锁。不过，需要强调一点，轻量级锁并不是用来代替重量级锁的，它设计的初衷是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

要理解轻量级锁，以及后面会讲到的偏向锁的原理和运作过程，必须要对HotSpot虚拟机对象的内存布局（尤其是对象头部分）有所了解。HotSpot虚拟机的对象头（Object Header）分为两部分，第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄（Generational GC Age）等。这部分数据的长度在32位和64位的Java虚拟机中分别会占用32个或64个比特，官方称它为“Mark Word”。这部分是实现轻量级锁和偏向锁的关键。另外一部分用于存储指向方法区对象类型数据的指针，如果是数组对象，还会有一个额外的部分用于存储数组长度。

轻量级锁的工作过程：

在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方为这份拷贝加了一个Displaced前缀，即Displaced Mark Word）。

然后，虚拟机将使用CAS操作尝试把对象的Mark Word更新为指向Lock Record的指针。如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象Mark Word的锁标志位（Mark Word的最后两个比特）将转变为“00”，表示此对象处于轻量级锁定状态。

如果这个更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了，否则就说明这个锁对象已经被其他线程抢占了。如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁，锁标志的状态值变为“10”，此时Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也必须进入阻塞状态

如果没有竞争，轻量级锁便通过CAS操作成功避免了使用互斥量的开销；但如果确实存在锁竞争，除了互斥量的本身开销外，还额外发生了CAS操作的开销。因此在有竞争的情况下，轻量级锁反而会比传统的重量级锁更慢。

偏向锁

偏向锁也是JDK 6中引入的一项锁优化措施，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不去做了。

它的意思是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步

偏向锁的原理

当前虚拟机启用了偏向锁（启用参数-XX：+UseBiased Locking，这是自JDK 6 起HotSpot虚拟机的默认值），那么当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为“01”、把偏向模式设置为“1”，表示进入偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁、解锁及对Mark Word的更新操作等）。

一旦出现另外一个线程去尝试获取这个锁的情况，偏向模式就马上宣告结束。根据锁对象目前是否处于被锁定的状态决定是否撤销偏向（偏向模式设置为“0”），撤销后标志位恢复到未锁定（标志位为“01”）或轻量级锁定（标志位为“00”）的状态，后续的同步操作就按照上面介绍的轻量级锁那样去执行。偏向锁、轻量级锁的状态转化及对象Mark Word的关系如图13-5所示。

偏向锁可以提高带有同步但无竞争的程序性能，但它同样是一个带有效益权衡（Trade Off）性质的优化，也就是说它并非总是对程序运行有利。如果程序中大多数的锁都总是被多个不同的线程访问，那偏向模式就是多余的。

synchronized 锁升级

以上JVM对锁的优化，就是 synchronized 锁升级的过程：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁

锁升级

为了减少锁操作的开销，JVM 引入了锁升级机制（锁膨胀），根据竞争激烈程度动态调整锁状态

无锁：初始状态，未锁定。

偏向锁：


  场景： 绝大多数时间只有一个线程访问。
  原理： Mark Word 记录偏向线程 ID。该线程进入同步块无需 CAS 操作，只需简单检查线程 ID。
  优点： 无竞争时开销极小（仅一次 CAS 初始化偏向）。
  升级： 当另一个线程尝试获取锁（检测到线程 ID 不一致），撤销偏向锁（需等待全局安全点），升级为轻量级锁。

轻量级锁：


  场景： 多个线程交替执行，无真正并发竞争。
  原理：
      线程在栈帧中创建锁记录（Lock Record）。
      通过 CAS 尝试将对象 Mark Word 复制到锁记录，并替换 Mark Word 为指向锁记录的指针。
      成功则获取锁；失败则自旋重试（循环尝试 CAS）。
  优点： 避免阻塞（用户态操作），减少 OS 线程切换开销。
  升级： 自旋超过一定次数（或自旋线程数增加），升级为重量级锁。

重量级锁：


  场景： 高并发竞争激烈。
  原理： 
      Mark Word 指向一个 ObjectMonitor 对象（操作系统互斥量 mutex 的封装）。
      未获取锁的线程进入阻塞队列，由 OS 负责调度唤醒。
  开销： 涉及用户态/内核态切换、线程阻塞与唤醒，开销最大。

锁升级方向：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁（不可逆）

Mark Word中锁升级的过程

为了可以在Java中看到对象头的MarkWord信息，需要导入依赖

xml
<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.9</version>
</dependency>

锁默认情况下，开启了偏向锁延迟。

偏向锁在升级为轻量级锁时，会涉及到偏向锁撤销，需要等到一个安全点（STW），才可以做偏向锁撤销，在明知道有并发情况，就可以选择不开启偏向锁，或者是设置偏向锁延迟开启

因为JVM在启动时，需要加载大量的.class文件到内存中，这个操作会涉及到synchronized的使用，为了避免出现偏向锁撤销操作，JVM启动初期，有一个延迟4s开启偏向锁的操作

如果正常开启偏向锁了，那么不会出现无锁状态，对象会直接变为匿名偏向

java
public static void main(String[] args) throws InterruptedException {
    Thread.sleep(5000);
    Object o = new Object();
    System.out.println(ClassLayout.parseInstance(o).toPrintable());

    new Thread(() -> {

        synchronized (o){
            //t1  - 偏向锁
            System.out.println("t1:" + ClassLayout.parseInstance(o).toPrintable());
        }
    }).start();
    //main - 偏向锁 - 轻量级锁CAS - 重量级锁
    synchronized (o){
        System.out.println("main:" + ClassLayout.parseInstance(o).toPrintable());
    }
}

整个锁升级状态的转变：

Lock Record以及ObjectMonitor存储的内容

2.5 重量锁底层ObjectMonitor

需要去找到openjdk，在百度中直接搜索openjdk，第一个链接就是

找到ObjectMonitor的两个文件，hpp，cpp

先查看核心属性：http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/69087d08d473/src/share/vm/runtime/objectMonitor.hpp

hpp
ObjectMonitor() {
    _header       = NULL;   // header存储着MarkWord
    _count        = 0;      // 竞争锁的线程个数
    _waiters      = 0,      // wait的线程个数
    _recursions   = 0;      // 标识当前synchronized锁重入的次数
    _object       = NULL;
    _owner        = NULL;   // 持有锁的线程
    _WaitSet      = NULL;   // 保存wait的线程信息，双向链表
    _WaitSetLock  = 0 ;
    _Responsible  = NULL ;
    _succ         = NULL ;
    _cxq          = NULL ;  // 获取锁资源失败后，线程要放到当前的单向链表中
    FreeNext      = NULL ;
    _EntryList    = NULL ;  // _cxq以及被唤醒的WaitSet中的线程，在一定机制下，会放到EntryList中
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ;
    _previous_owner_tid = 0;
  }

适当的查看几个C++中实现的加锁流程

http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/69087d08d473/src/share/vm/runtime/objectMonitor.cpp

TryLock

cpp
int ObjectMonitor::TryLock (Thread * Self) {
   for (;;) {
	  // 拿到持有锁的线程
      void * own = _owner ;
      // 如果有线程持有锁，告辞
      if (own != NULL) return 0 ;
      // 说明没有线程持有锁，own是null，cmpxchg指令就是底层的CAS实现。
      if (Atomic::cmpxchg_ptr (Self, &_owner, NULL) == NULL) {
		 // 成功获取锁资源
         return 1 ;
      }
      // 这里其实重试操作没什么意义，直接返回-1
      if (true) return -1 ;
   }
}

try_entry

cpp
bool ObjectMonitor::try_enter(Thread* THREAD) {
  // 在判断_owner是不是当前线程
  if (THREAD != _owner) {
    // 判断当前持有锁的线程是否是当前线程，说明轻量级锁刚刚升级过来的情况
    if (THREAD->is_lock_owned ((address)_owner)) {
       _owner = THREAD ;
       _recursions = 1 ;
       OwnerIsThread = 1 ;
       return true;
    }
    // CAS操作，尝试获取锁资源
    if (Atomic::cmpxchg_ptr (THREAD, &_owner, NULL) != NULL) {
      // 没拿到锁资源，告辞
      return false;
    }
    // 拿到锁资源
    return true;
  } else {
    // 将_recursions + 1，代表锁重入操作。
    _recursions++;
    return true;
  }
}

enter（想方设法拿到锁资源，如果没拿到，挂起扔到_cxq单向链表中）

cpp
void ATTR ObjectMonitor::enter(TRAPS) {
  // 拿到当前线程
  Thread * const Self = THREAD ;
  void * cur ;
  // CAS走你，
  cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
  if (cur == NULL) {
     // 拿锁成功
     return ;
  }
  // 锁重入操作
  if (cur == Self) {
     // TODO-FIXME: check for integer overflow!  BUGID 6557169.
     _recursions ++ ;
     return ;
  }
  //轻量级锁过来的。
  if (Self->is_lock_owned ((address)cur)) {
    _recursions = 1 ;
    _owner = Self ;
    OwnerIsThread = 1 ;
    return ;
  }


  // 走到这了，没拿到锁资源，count++
  Atomic::inc_ptr(&_count);

  
    for (;;) {
      jt->set_suspend_equivalent();
      // 入队操作，进到cxq中
      EnterI (THREAD) ;
      if (!ExitSuspendEquivalent(jt)) break ;
      _recursions = 0 ;
      _succ = NULL ;
      exit (false, Self) ;
      jt->java_suspend_self();
    }
  }
  // count--
  Atomic::dec_ptr(&_count);
  
}

EnterI

cpp
for (;;) {
    // 入队
    node._next = nxt = _cxq ;
    // CAS的方式入队。
    if (Atomic::cmpxchg_ptr (&node, &_cxq, nxt) == nxt) break ;

    // 重新尝试获取锁资源
    if (TryLock (Self) > 0) {
        assert (_succ != Self         , "invariant") ;
        assert (_owner == Self        , "invariant") ;
        assert (_Responsible != Self  , "invariant") ;
        return ;
    }
}

注意事项与最佳实践

明确锁对象：确保所有需要互斥的线程竞争的是同一个锁对象。

减小锁粒度：


  优先使用同步代码块而非同步方法。
  避免在方法上使用 synchronized（锁住整个对象）。
  使用细粒度锁（如 ConcurrentHashMap 的分段锁思想）。

缩短临界区：


  只将真正需要互斥的代码放入同步块。
  避免在临界区内执行耗时操作（IO、复杂计算）。

避免锁不可变对象：

java
private final String lock = "LOCK"; // 危险！字符串常量池唯一性可能导致意外锁竞争

避免死锁：


  按固定顺序获取多个锁。
  设置锁超时（synchronized 本身不支持，需用 Lock.tryLock）。
  避免嵌套锁。

考虑替代方案：


  java.util.concurrent.locks.Lock 接口（如 ReentrantLock）提供更灵活的功能（可中断、公平锁、多条件变量）。
  java.util.concurrent 包中的并发容器（ConcurrentHashMap, CopyOnWriteArrayList）通常性能更好。
  volatile 关键字（保证可见性，不保证原子性）。
  原子类（AtomicInteger 等，基于 CAS）。

何时使用 synchronized？

需要实现简单的互斥访问。
临界区代码逻辑简单且执行快速。
锁竞争程度不高。
对锁的高级特性（如公平性、可中断性）无特殊要求。

总结

synchronized 是 Java 并发编程的基石。理解其基于监视器锁的原理、锁升级优化过程以及使用时的注意事项，是写出高效、安全并发代码的关键。在现代高并发应用中，虽然 java.util.concurrent 包提供了更丰富的工具，synchronized 因其简洁性和 JVM 的持续优化，仍然是许多场景下的可靠选择。开发者应结合具体需求，在简单性、性能和功能之间做出权衡。

目录

synchronized 的本质：监视器锁（Monitor Lock）

锁的获取与释放规则

synchronized 的使用方式

深入 JVM：synchronized 的底层实现

字节码层面

对象头与 Mark Word

锁的可重入性

锁优化：性能优化之路（JDK 6+）

自旋锁与自适应自旋

自旋锁

自适应自旋锁

锁消除

锁粗化

轻量级锁

偏向锁

锁升级

Mark Word中锁升级的过程

2.5 重量锁底层ObjectMonitor

注意事项与最佳实践

总结