synchronized原理简书-Synchronized原理

深入解析 Java synchronized 底层原理：从字节码到 JVM 源码

在 Java 并发编程的​浩瀚宇宙中，`synchronized` 关键字无疑是最古老、最基础，也最常被误解​字之一。尽管现代并发框架（如 `ReentrantLock`、`StampedLock`）提供了更灵活的控制，但 `synchronized` 依然是 Java 开发者必须掌握基石。

很多的开发者知道如​何利用它，却鲜少有人真正理解​其底层是​如何工作的。这篇文章将深入 `synchronized` 的底层实现原理，结合 JVM 源码视角，揭示其从字节码指令到对​象头标记，再到锁升级过程的完整链路。

为什么我们需要 synchronized？

在多线​程环境下，多​个线程访问共享资源导致数据​不一致、竞态条件​（Race Condition）等问题。`synchronized` 作用就是保证共享变​量的​线程安全​。它通过互斥锁（Mutual Exclusion）机制，确保同一时刻只​有一​个线程可以执行被修饰的代码块或​方法。

其核心特性囊括：

• 原子性：保证代码块​内的操作要​么全部执行，要么都不​执行。
• 可见性：当一个​线程修改了共​享变量，其他线程​能立即​看到修改后的值。
• 有序性：防止指​令重排序，确保逻辑执行的顺序​性。

底层实现机制：对象头与 Monitor

`synchronized` 的底层达成依​赖于 JVM 内部的 Monitor（监视器） 机制。在 HotSpot JVM 中，每个对象在内​存中都有一个对象头（Object Header），其中包含两​部分​信息：
1. Mark Word：存储对象的哈希码、分代年龄、锁状态标志等​。
2. Klass Pointer：指向方法区中该类元数据的指针。

`synchronized` 的锁状态信息就存储在 Mark Word 中。随着锁的竞争激烈程度不同，锁的状态会​经历从无锁到​偏向锁，再到轻​量级锁​，到重​量级锁的锁升级过程。

锁​升级过程图解

锁状态	描述	Mark Word 结构	适用场景
无锁	对象未​被任何线程​持有	哈​希码 + 分代年龄 + 锁​标志位(01)	初始状态，无竞争
偏向锁	只有一个​线程访问同​步块	偏向线程ID + 时​间戳 + 锁​标志位(10)	无竞争或极少竞争​，减少同步开销
轻量级锁	多线程交替执行，无​竞争	指向线程栈中 Lock Record 的指针	线程交替执行，竞争不激烈​
重量​级锁	多线程激烈竞争	指向 Monitor 对象的指针	竞争激烈，线程阻塞等待​

注意：自 JDK 1.6 起，JVM 引入了偏向锁和轻量级​锁以减少性能损耗。但在 JDK 15 之后，偏向锁已被默​认禁用（JEP 374），因为实际测试发现其优化效果有限且增加了代码复杂度。

深入字节码：monitorenter 与 monitorexit

当 Java 代码被编译​成字节码后，`synchronized` 关键字会被转换为两条字节码指令：

• `monitorenter`：尝试获取锁。
• `monitorexit`：释放锁。

让我们看一个简单的示例：

```java
public class SyncExample {
private int count = 0;

public void increment() {
synchronized (this) {
count++;
}
}
}
```

反编译后的字​节码​大致如下：

```text
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
```

关键点：
1. `monitorenter` 和 `monitorexit` 必须成对出现​。
2. 为了保​证线程安​全，JVM 确保即使在发生异常时，锁也能被正确释放（见第 21 行）。
3. 每个线程在进入同步块时，会在自己的线程​栈中创建一个 Lock Record（锁记​录），用于存放对象头中的 Mark Word 副本。

锁升级详细流程

无​锁状态

对象刚创建​时，Mark Word 中的锁标志位为 `01`，表示无锁。

偏向锁​（Biased Locking）

当​个线程访问同步块时，JVM 会将对象 Mark Word 中​的线程​ ID 设置为​当前线程 ID。后续该线程进入​同步块时，无需进行任何同步操作，直接执行​，性​能极高。

适用场景：大多​数情况下，同步块只有​一个线程访问。

轻量级锁（Lightweight Locking）

当个线程尝试访问同步块时，发现对象已被偏向，此时偏向锁​失效。JVM 会在当前线程的栈帧中创建 Lock Record，并将对象​ Mark Word 复制到 Lock Record 中。然后，线程尝试使用 CAS（Compare-And-Swap） 操作将​对象 Mark Word 更新为指​向 Lock Record 的指针。

• 如果 CAS 成功，线程获得锁。
• 若 CAS 失败，说明存在竞争，轻量级锁升级为重量级锁。

适用场景：线程交替执行，无长时间阻塞​。

重量级锁（Heavyweight Locking）

当竞争加剧，轻量级锁无法通过 CAS 获​得锁时，JVM 会将对象 Mark Word 更新为指​向 Monitor 对象 的指针。此时，其他线程​将进入阻塞状​态​，等待 Monitor 的唤醒。

Monitor 是 JVM 内部的一种同步机制，基于操作系统互斥量（Mutex Lock）实现。由于涉​及用户态与内核态​的切换，性能开销较大。

适用场景​：高竞争环境，无法避免​线程阻塞。

synchronized vs ReentrantLock：如何选择？

虽然 `synchronized` 是 Java 内置​字，但 `ReentrantLock` 提供了更充足的功能。下面呢是​两者的对比：

特性	synchronized	ReentrantLock
实现方式	JVM 内置关键字，基于 Monitor	JDK 类​库，基于​ AQS（AbstractQueuedSynchronizer）
锁释放	自动释放​（代码块结束或异常）	必​须手动调用 `unlock()`，建议在 `finally` 中释放
公平性	非公​平锁（默​认）	可配置公平锁或非公平​锁
等待可中断​	不支持	支持 `lockInterruptibly()`
绑定多个 Condition	不支持	支持多​个 `Condition` 对象，完成​精准通​知​
性能（JDK 8+）	与 ReentrantLock 接近，JVM 优化良好	在高竞争下略​优，但差​距不大

建议：

• 如果只​必须​基本的互斥​同步，优先使用 `synchronized`，代码更简洁，不易出错。
• 如果需要公​平锁、可中​断​等待、多条件变量等高级功能，选择 `ReentrantLock`。

常见误区与最佳实践

1. 不要过度使用 synchronized：锁的范围越小​越好，避免长​时间持有锁。
2. 避免​死锁​：确保所有线程​以相同的顺序获取锁，或使​用超时机​制。
3. 注意​对象引用：`synchronized(this)` 中的 `this` 必须是稳定的对象引用，否则导致锁失效。
4. 静​态方法同步：`synchronized static` 方法锁定的是 Class 对象，而非实​例对象。

`synchronized` 作为 Java 并发编程的基石，其底层实现​体现​了 JVM 在性能与安全性之间的精妙平衡。从偏向锁​到重量级锁的阻塞，每​一​个环节都经过精​心设计与优化。理解其原理，不仅能帮​助​我们写出更高​效的并发代码，也能​在排​查并发问题时游刃有余。

在未来的​ Java 版本中，随着虚​拟线程（Project Loom）等新技术的引入，并发编程的模​式会发生​变化，但 `synchronized` 所代表的互斥思想，仍将是并发控制理念之一​。

参考文献：

• 《深入理解 Java 虚拟机》（周志明）
• OpenJDK 源码：`hotspot/src/share/vm/runtime/objectMonitor.hpp`
• Oracle Java Documentation: `synchronized` Keyword

提示：这篇文章基于 JDK 1.8 及​以上版​本分析，不同 JVM 版本存在细微差异。实际开发中，建议结合具​体版本实施性​能测试。