在Java并发编程的宏大版图中，synchronized 关键字无疑是最具历史底蕴且至今仍不可或缺的基石。自Java 1.0诞生之初便伴随左右，它曾因其“重量级”的性能损耗而备受诟病，但随着JVM技术的不断演进（特别是Java 6引入的锁升级机制），synchronized已蜕变为一个高效、智能且易于使用的同步工具。很多开发者在日常编码中频繁使用它，却未必深究其背后的运作机理：synchronized 关键字是什么？有什么作用？ 它是如何保证线程安全的？在现代JVM中它经历了怎样的优化？本文将深入HotSpot虚拟机底层，结合对象头结构、字节码指令及锁升级流程，为你彻底揭开synchronized的神秘面纱。
一、synchronized 的核心定义与三大作用
synchronized是Java语言提供的内置关键字，用于实现线程同步（Thread Synchronization）。它的核心目标是解决多线程环境下共享资源访问的冲突问题，确保同一时刻只有一个线程能执行特定的代码段或方法。
1.1 保证原子性（Atomicity）
原子性是指一个操作或多个操作要么全部执行成功，要么全部不执行，不可被中断。synchronized通过互斥锁机制，确保当一个线程进入同步代码块时，其他线程无法同时进入，从而将一系列操作打包成一个不可分割的原子单元。
- 场景：银行转账操作（扣减A账户 + 增加B账户）必须作为一个整体执行，防止中间状态被其他线程读取。
1.2 保证可见性（Visibility）
可见性是指当多个线程访问同一个变量时，一个线程修改了该变量的值，其他线程能够立即看到这个修改。synchronized遵循Java内存模型（JMM）的happens-before规则：
- 解锁前：线程必须将工作内存中的共享变量刷新到主内存。
- 加锁后：线程必须从主内存重新加载共享变量到工作内存。
这一机制确保了线程间数据的实时同步，避免了因CPU缓存不一致导致的脏读问题。
1.3 保证有序性（Ordering）
有序性是指程序执行的顺序按照代码的先后顺序执行。虽然编译器和处理器常会对指令进行重排序优化，但synchronized限制了这种重排：在同一时刻，只允许一个线程执行同步代码，相当于将并行执行强制转换为串行执行，从而天然地保证了操作的有序性。
二、synchronized 的三种使用范式与锁对象
synchronized的使用非常灵活，根据修饰对象的不同，其锁定的目标（Monitor Owner）也有所区别。理解“锁的是什么”是避免死锁和性能陷阱的关键。
2.1 修饰实例方法
public synchronized void method() {
// 业务逻辑
}
- 锁对象：当前实例对象（
this）。 - 作用范围：同一实例对象的多个同步方法互斥。不同实例对象之间的同步方法可以并发执行。
- 适用场景：保护实例变量的线程安全。
2.2 修饰静态方法
public static synchronized void staticMethod() {
// 业务逻辑
}
- 锁对象：当前类的Class对象（
ClassName.class）。 - 作用范围：整个类的所有实例共享同一把锁。无论创建多少个对象，该静态同步方法同一时刻只能被一个线程访问。
- 适用场景：保护静态变量或类级别的全局资源。
2.3 修饰代码块
public void method() {
synchronized (lockObject) {
// 业务逻辑
}
}
- 锁对象：括号内指定的对象（
lockObject）。可以是this、Class对象、字符串常量池中的字符串（不推荐）或专用的私有final对象（推荐）。 - 作用范围：仅同步代码块内部的内容，粒度更细，性能通常优于修饰整个方法。
- 最佳实践：
// 推荐：使用私有的final对象作为锁，避免外部干扰 private final Object lock = new Object(); public void safeMethod() { synchronized (lock) { // ... } }切忌使用字符串常量或自动装箱的Integer作为锁对象，因为它们可能被全局共享，导致意外的锁竞争甚至死锁。
三、底层原理：Monitor 与 对象头
synchronized的底层实现依赖于监视器锁（Monitor）。在HotSpot虚拟机中，Monitor并非实体对象，而是基于C++实现的互斥量，与Java对象头紧密绑定。
3.1 Java对象头（Object Header）
每个Java对象在内存中都包含一个对象头，其中存储了对象的哈希码、GC分代年龄、锁状态标志等信息。对于64位JVM，对象头通常包含两部分：
- Mark Word：存储运行时数据，如哈希码、分代年龄、锁标志位、偏向线程ID等。
synchronized的锁状态信息就存储在Mark Word中。 - Klass Pointer：指向类元数据的指针，确定对象是哪个类的实例。
3.2 Monitor 的工作机制
当线程尝试进入同步块时，JVM会检查对象头的Mark Word：
- 如果对象未被锁定，线程尝试获取锁。
- 如果对象已被锁定，线程根据锁的状态（偏向、轻量、重量）决定是自旋、阻塞还是升级锁。
- 一旦获取锁，Mark Word会被更新为包含当前线程ID和锁状态的信息。
- 线程退出同步块时，释放锁，恢复Mark Word。
四、锁升级机制：从偏向锁到重量级锁的进化
为了减少获得锁和释放锁带来的性能消耗（用户态与内核态的切换），Java 6引入了锁升级（Lock Escalation）机制。锁的状态总共有四种：无锁、偏向锁、轻量级锁、重量级锁。状态随着竞争的加剧逐渐升级，不可降级。
4.1 无锁（No Lock）
对象头中没有锁标记，所有线程均可自由访问。这是对象的初始状态。
4.2 偏向锁（Biased Locking）
- 场景：适用于只有一个线程访问同步代码的场景（无竞争）。
- 原理：当第一个线程访问锁时，JVM将对象头的Mark Word标记为“偏向模式”，并记录该线程的ID。后续该线程再次进入同步块时，无需任何CAS操作，直接判断线程ID匹配即可通过。
- 优势：极大降低了单线程下的同步开销。
- 注意：在Java 15及以后版本中，偏向锁默认被禁用（因现代应用多为多线程竞争，偏向锁维护成本反而高），但在旧版本或特定调优下仍有效。
4.3 轻量级锁（Lightweight Locking）
- 场景：存在轻微竞争，多个线程交替执行同步块，但未同时竞争。
- 原理：当有第二个线程尝试获取偏向锁时，偏向锁升级为轻量级锁。线程会在自己的栈帧中创建锁记录（Lock Record），并通过CAS操作尝试将对象头的Mark Word替换为指向锁记录的指针。
- 成功：获取锁，执行代码。
- 失败：说明有竞争，线程自旋（Spin）等待，不阻塞挂起。
- 优势：避免了用户态到内核态的切换，通过自旋减少上下文切换开销。
4.4 重量级锁（Heavyweight Locking）
- 场景：存在激烈竞争，自旋一定次数后仍未获取锁。
- 原理：轻量级锁膨胀为重量级锁。此时对象头的Mark Word指向一个Monitor对象（ObjectMonitor）。未获取锁的线程将被操作系统阻塞（Blocked），挂入等待队列，释放CPU资源。
- 代价：涉及用户态与内核态的切换，开销最大。但能保证在高竞争下系统的稳定性。
锁升级流程图示：无锁 -> 偏向锁 (单线程) -> 轻量级锁 (CAS自旋) -> 重量级锁 (阻塞排队)
五、synchronized 的优缺点与最佳实践
5.1 优点
- 简单易用：语法简洁，无需手动管理锁的获取与释放（自动隐式释放）。
- 功能完备：原生支持可重入、非公平锁（默认）、条件变量（配合wait/notify）。
- 持续优化：随着JVM升级，性能不断提升，在中等竞争场景下表现优异。
5.2 缺点
- 灵活性不足：无法像
ReentrantLock那样尝试获取锁（tryLock）、设置超时或响应中断。 - 黑盒操作：锁的状态和竞争情况难以监控和调试。
- 潜在死锁：若嵌套使用不当，容易引发死锁，且排查困难。
5.3 最佳实践与避坑指南
- 缩小锁粒度：尽量使用同步代码块而非同步整个方法，减少持有锁的时间。
- 避免锁粗化：不要在循环内部重复加锁，应将锁移到循环外部。
- 不要锁住常量：严禁使用
String.intern()返回的字符串或自动装箱的基本类型作为锁对象，防止全局冲突。 - 优先使用私有锁对象：定义
private final Object lock = new Object();，确保锁不会被外部代码意外获取。 - 读写分离：对于读多写少的场景，考虑使用
ReentrantReadWriteLock或StampedLock替代synchronized以提升并发度。
六、总结
synchronized作为Java并发编程的“定海神针”，凭借其简洁的语法和JVM底层的深度优化，依然是大多数场景下的首选同步方案。从对象头的Mark Word到Monitor监视器，从无锁到重量级锁的动态升级，这一系列精妙的设计使得它在保证线程安全的同时，尽可能减少了性能损耗。
理解synchronized不仅仅是掌握一个关键字，更是理解JVM如何协调多线程资源、如何平衡性能与安全的过程。在未来的开发中，虽然java.util.concurrent包提供了更多高级工具，但synchronized凭借其稳定性和易用性，仍将占据重要地位。
