Java synchronized 深入解析：从字节码指令到锁升级机制

2.2 Monitor（管程/监视器锁）

JVM 为每个对象都关联了一个内置的 Monitor（管程）。monitorenter 指令的本质就是尝试去获取这个对象对应的 Monitor。

一个 Monitor 主要由以下部分组成：

• Owner：当前持有该 Monitor 的线程。初始为 null。
• EntryList：处于 BLOCKED 状态的、等待锁的线程队列。
• WaitSet：处于 WAITING 状态的、调用了 Object.wait() 方法的线程队列。

工作流程简述： 当线程执行到 monitorenter 指令时，会尝试进入该对象的 Monitor。如果 Owner 为 null，则成为 Owner；如果已经是 Owner（可重入锁），计数器 +1；如果是其他线程持有，则进入 EntryList 阻塞。执行 monitorexit 时，计数器 -1，减到 0 时释放 Monitor，EntryList 中的线程开始竞争。

3. 锁的升级与优化

在 Java 6 之前，synchronized 是一个重量级锁，性能较差，因为它依赖于操作系统的 Mutex Lock，涉及用户态到内核态的切换。为了减少开销，Java 6 引入了锁升级机制。锁状态从低到高分为四种，升级路径是单向的：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁。

3.1 偏向锁

• 目的：在没有竞争的情况下，消除整个同步操作。假设大多数情况下锁总是由同一线程多次获得。
• 原理：当一个线程访问同步块时，会在对象头和栈帧中的锁记录里存储偏向的线程 ID。以后该线程再次进入，只需测试 Mark Word 是否指向当前线程，无需 CAS 操作。
• 撤销：一旦出现另一个线程尝试竞争锁，偏向模式结束。持有偏向锁的线程会被挂起，JVM 撤销偏向锁，升级为轻量级锁。

注意：在 Java 15 之后，偏向锁被标记为废弃并默认禁用，因为维护收益已不如从前，但理解其原理依然重要。

3.2 轻量级锁

• 目的：在竞争不激烈（'近交替执行'）的情况下，避免直接使用重量级锁带来的性能消耗。
• 加锁过程：
  1. 在当前线程的栈帧中创建一个名为 锁记录 的空间。
  2. 将对象头的 Mark Word 复制到锁记录中（Displaced Mark Word）。
  3. 线程尝试使用 CAS 操作将对象头的 Mark Word 替换为指向锁记录的指针。
     • 成功：获得锁，Mark Word 最后 2 位设为 00。
     • 失败：存在竞争，需自旋或升级。
• 解锁过程：使用 CAS 操作将 Displaced Mark Word 替换回对象头。如果失败，说明锁已升级，需唤醒被挂起的线程。

3.3 重量级锁

• 触发条件：当轻量级锁竞争失败后，会自旋尝试获取锁一定次数。如果自旋后依然失败，锁就会膨胀为重量级锁。
• 特点：此时 Mark Word 中存储的是指向重量级锁（Monitor）的指针。等待锁的线程都会进入 EntryList，进入 BLOCKED 状态，依赖操作系统底层的 Mutex Lock，成本最高。

4. 硬件层面：内存屏障与 CAS

synchronized 的语义保证了原子性、可见性和有序性。

• 可见性与有序性：通过插入 内存屏障 实现。在同步块开始时加 Load Barrier，结束时加 Store Barrier，强制刷新工作内存到主内存，禁止指令重排序。
• 原子性：对于简单的 monitorenter/monitorexit，由 Monitor 保证。对于锁升级过程中的状态变更，则是通过 CAS 操作实现的。CAS 是一条 CPU 原子指令（cmpxchg），保证了'比较 - 交换'操作的原子性。

理解这些底层机制，能帮助我们在实际开发中更合理地选择同步策略，写出更高效、安全的并发代码。