Object Header 对象头

在 32 位虚拟机下，一个普通 Java 对象的对象头（Object Header）总长度为 64 bit（8 字节），由两部分组成：

• Klass Word（类型指针）：32 bit（4 字节）

• Mark Word（标记字）：32 bit（4 字节）

---

Klass Word（类型指针）

是一个指向方法区中该对象对应类元数据的指针，虚拟机通过它来确定这个对象是哪个类的实例。

在 32 位虚拟机中，它固定占用 4 字节；在 64 位虚拟机中，如果开启了指针压缩（默认开启），它会被压缩为 4 字节，否则为 8 字节。

Mark Word 标记字

这是对象头里最核心的部分，主要存储对象自身的运行时数据，包括：

• 哈希码（HashCode）：对象的哈希值

• GC 分代年龄：对象在新生代中熬过的 GC 次数

• 锁状态信息：偏向锁、轻量级锁、重量级锁的标记

• 偏向线程 ID：如果是偏向锁，记录持有锁的线程 ID

• 偏向时间戳：偏向锁的时间戳

它的结构会根据对象的锁状态动态变化，是实现 synchronized 锁升级的关键。

Monitor 原理

Monitor 被翻译为监视器或管程，每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针。

1. 初始与加锁阶段：初始状态下，对象对应的 Monitor 中 Owner（所有者）属性为 null，无任何线程持有该监视器锁；当某个线程进入 synchronized 修饰的方法 / 代码块时，会将该 Monitor 的 Owner 置为当前线程，Monitor 的 Owner 具有唯一性，同一时间仅能有一个线程成为 Owner 并持有锁。

2. 锁竞争失败处理：当已有线程持有 Monitor 锁时，其他线程若尝试进入同步块 / 方法，会因锁竞争失败进入 Monitor 的 EntryList（入口队列），此时这些线程的状态会转变为 BLOCKED（阻塞状态），等待锁资源释放后参与竞争。

3. wait () 方法执行逻辑：持有 Monitor 锁的线程在执行过程中，若调用目标对象的 wait () 方法，会主动释放锁，同时自身进入 Monitor 的 WaitSet（等待集合），线程状态从 RUNNABLE 转变为 WAITING。

4. notify/notifyAll 唤醒逻辑：当后续成功获取该 Monitor 锁的线程，执行目标对象的 notify () 方法 /notifyAll () 方法时，会唤醒该对象 Monitor 的 WaitSet 中处于等待状态的线程。

5. WaitSet 唤醒线程的竞争逻辑：从 WaitSet 中被 notify ()/notifyAll () 唤醒的线程，会直接退出 WaitSet，线程状态从 WAITING 转变为 RUNNABLE 状态，具备 Monitor 锁的竞争资格（而非进入 EntryList 队列）；这些线程会与 EntryList 中等待锁的线程共同参与锁竞争。

6. 锁释放与 EntryList 唤醒逻辑：持有 Monitor 锁的线程执行完 synchronized 同步块 / 方法后，会释放该锁（将 Owner 置为 null），并仅唤醒 EntryList 中的一个线程；该被唤醒的线程状态从 BLOCKED 转变为 RUNNABLE，与第 5 点中已处于 RUNNABLE 状态的 WaitSet 唤醒线程、甚至新尝试加锁的线程一起，通过非公平锁机制竞争 Monitor 锁。

synchronized 原理

static final Object lock = new Object(); 
static int counter = 0;
 
public static void main(String[] args) { synchronized (lock) {
    counter++;
    }
}

对应的字节码为：

public static void main(java.lang.String[]);
  descriptor: ([Ljava/lang/String;)V
  flags: ACC_PUBLIC, ACC_STATIC
  Code:
    stack=2, locals=3, args_size=1
       0: getstatic     #2                  // <- lock引用 （synchronized开始）
       3: dup
       4: astore_1                          // lock引用 -> slot 1
       5: monitorenter                      // 将 lock对象 MarkWord 置为 Monitor 指针
       6: getstatic     #3                  // <- i
       9: iconst_1                          // 准备常数 1
      10: iadd                              // +1
      11: putstatic     #3                  // -> i
      14: aload_1                           // <- lock引用
      15: monitorexit                       // 将 lock对象 MarkWord 重置, 唤醒 EntryList
      16: goto          24
      19: astore_2                          // e -> slot 2
      20: aload_1                           // <- lock引用
      21: monitorexit                       // 将 lock对象 MarkWord 重置, 唤醒 EntryList
      22: aload_2                           // <- slot 2 (e)
      23: athrow                            // throw e
      24: return
      
      Exception table:
         from    to  target type
             6    16    19   any
            19    22    19   any

     LineNumberTable:
      line 8: 0
      line 9: 6
      line 10: 14
      line 11: 24
    
     LocalVariableTable:
      Start  Length  Slot  Name   Signature
          0      25     0  args   [Ljava/lang/String;

     StackMapTable: number_of_entries = 2
      frame_type = 255 /* full_frame */
        offset_delta = 19
        locals = [ class "[Ljava/lang/String;", class java/lang/Object ]
        stack = [ class java/lang/Throwable ]
      frame_type = 250 /* chop */
        offset_delta = 4

synchronized 进阶原理

轻量级锁

轻量级锁的使用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（没有竞争），那么可以使用轻量级锁来优化。

轻量级锁对使用者是透明的，即语法仍然是 假设有两个方法同步块，利用同一个对象加锁。

static final Object obj = new Object(); 

public static void method1() {
    synchronized( obj ) {
        // 同步块 A 
        method2();
        }
    }

public static void method2() { 
    synchronized( obj ) {
        // 同步块 B
        }
    }

1. 创建锁记录（Lock Record）：线程准备进入同步块时，JVM 会在它的栈帧里开辟一块空间，叫锁记录，然后把对象头里的 Mark Word 完整复制一份进去，这份复制出来的内容就叫 Displaced Mark Word（可以理解为 "备份的对象头"）。

2. CAS 尝试获取锁：线程会用 CAS 原子操作，把对象头里的 Mark Word 替换成一个指向自己栈帧里锁记录的指针。

3. 如果 CAS 成功：说明没有其他线程竞争，当前线程成功获得锁，Mark Word 里存着指向锁记录的指针。

4. 如果 cas 失败，有两种情况：

1. 如果是其它线程已经持有了该 Object 的轻量级锁，这时表明有竞争，进入锁膨胀过程；

2. 如果是自己执行了 synchronized 锁重入，那么再添加一条 Lock Record 作为重入的计数。

5. 当退出 synchronized 代码块（解锁时）如果有取值为 null 的锁记录，表示有重入，这时重置锁记录，表示重入计数减一。

6. 当退出 synchronized 代码块（解锁）锁记录的值不为 null，这时使用 CAS 将 Mark Word 的值恢复给对象头。

1. 成功，则解锁成功；

2. 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程。

锁膨胀

如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。

static Object obj = new Object(); 

public static void method1() {
    synchronized( obj ) {
    // 同步块
    }
}

当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁。

这时 Thread-1 加轻量级锁失败，进入锁膨胀流程，即为 Object 对象申请 Monitor 锁，让 Object 指向重量级锁地址，然后自己进入 Monitor 的 EntryList BLOCKED。

当 Thread-0 退出同步块解锁时，使用 CAS 将 Mark Word 的值恢复给对象头，失败。这时会进入重量级解锁流程，即按照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程。

自旋优化

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。

线程 1（core 1 上）	对象 Mark	线程 2（core 2 上）
-	10（重量锁）	-
访问同步块，获取 monitor	10（重量锁）重量锁指针	-
成功（加锁）	10（重量锁）重量锁指针	-
执行同步块	10（重量锁）重量锁指针	-
执行同步块	10（重量锁）重量锁指针	访问同步块，获取 monitor
执行同步块	10（重量锁）重量锁指针	自旋重试
执行同步块	10（重量锁）重量锁指针	自旋重试
执行同步块	10（重量锁）重量锁指针	自旋重试
执行同步块	10（重量锁）重量锁指针	阻塞
-	...	...

• 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。

• 在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。

• Java 7 之后不能控制是否开启自旋功能。

偏向锁

轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。

Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有。

static final Object obj = new Object();
public static void m1() {
    synchronized( obj ) {
        // 同步块 A
        m2();
    }
}

public static void m2() {
    synchronized( obj ) {
        // 同步块 B
        m3();
    }
}

public static void m3() {
    synchronized( obj ) {
        // 同步块 C
    }
}

偏向状态

回忆一下对象头格式

一个对象创建时：

1. 如果开启了偏向锁（默认开启），那么对象创建后，markword 值为 0x05 即最后 3 位为 101，这时它的 thread、epoch、age 都为 0。

2. 如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即最后 3 位为 001，这时它的 hashcode、 age 都为 0，第一次用到 hashcode 时才会赋值。

3. 偏向锁默认是延迟的，如果想在程序启动时立即生效，可加 VM 参数-XX:BiasedLockingStartupDelay=0来禁用延迟。

4. 代码运行时，添加 VM 参数-XX:-UseBiasedLocking禁用偏向锁。

锁撤销

1. 调用对象 hashCode

当调用对象的 hashCode 方法时，会触发不同锁状态下的 hashCode 存储逻辑调整：

• 若对象处于偏向锁状态，由于偏向锁的 Mark Word 中存储的是持有锁的线程 ID，无 hashCode 存储位置，因此调用 hashCode 会直接导致偏向锁被撤销；

• 若对象处于轻量级锁状态，hashCode 会被记录在当前线程的锁记录（Lock Record）中；

• 若对象处于重量级锁状态，hashCode 则会被记录在对象对应的 Monitor 监视器中。

---

2. 其它线程使用对象

当存在其他线程尝试获取已被偏向的锁对象时，JVM 会将该对象的偏向锁升级为轻量级锁。

---

3. 调用 wait/notify 方法

wait()/notify() 方法依赖重量级锁的 Monitor 监视器实现，因此调用这类方法会直接导致偏向锁被撤销，并升级为重量级锁（而非先升级为轻量级锁）。

批量重偏向

批量重偏向是 JVM 针对偏向锁撤销过于频繁而设计的一种优化策略：当同一个类的多个对象都发生了偏向锁撤销（比如不同线程交替使用这些对象，默认阈值20次），JVM 不会对每个对象都单独撤销偏向锁，而是直接将这个类的所有偏向锁对象集体重偏向到当前获取锁的线程，以此减少大量重复的偏向锁撤销操作，提升性能。

直接修改这些对象的 Mark Word：把它们的偏向锁从 "偏向线程 1" 改成 "当前获取锁的线程 "

---

为什么需要批量重偏向？

如果没有批量重偏向，当一个类的多个对象频繁被不同线程获取偏向锁时，每个对象都会反复经历 "偏向锁→撤销→轻量级锁" 的过程，这会产生大量额外开销。批量重偏向的核心目的就是避免这种 "重复撤销" 的低效行为。

批量撤销

批量撤销是 JVM 针对偏向锁极端频繁撤销场景设计的终极优化策略：当同一个类的对象偏向锁撤销次数超过默认阈值（40 次）后，JVM 判定该类对象本身不适合使用偏向锁，于是会将这个类的所有对象直接设置为不可偏向状态（偏向锁特性失效），且后续新建的该类对象也会默认处于不可偏向状态，以此彻底避免偏向锁反复撤销带来的性能损耗。

锁消除

锁消除是 JVM 针对无实际竞争的锁场景设计的极致性能优化策略：当 JVM 通过逃逸分析判定一段代码中的锁对象仅在当前线程内使用（无逃逸、无多线程竞争可能）时，JVM 会直接消除该锁的获取与释放操作，以此彻底避免无意义的锁开销，提升程序执行效率。

锁粗化

锁粗化是 JVM 针对频繁获取、释放同一把锁的场景设计的性能优化策略：当 JVM 检测到一段代码中频繁对同一把锁进行获取与释放操作（比如循环内多次加锁、解锁）时，JVM 会将这些分散的、连续的锁操作合并为一次全局的锁获取与释放，即扩大锁的作用范围，以此减少频繁加解锁带来的上下文切换和性能开销，提升程序执行效率。

wait notify 原理

Owner 线程发现条件不满足，调用 wait 方法，即可进入 WaitSet 变为 WAITING 状态

BLOCKED 状态和 WAITING 状态的线程均处于阻塞状态，不会占用 CPU 时间片，仅等待被唤醒后参与锁竞争。

BLOCKED 线程：会在 Owner 线程释放锁时被唤醒其中一个（状态转为 RUNNABLE），参与锁的非公平竞争；

WAITING 线程：仅会在持有锁的 Owner 线程调用该对象的 notify ()/notifyAll () 时被唤醒，唤醒后线程状态转为 RUNNABLE（不会进入 EntryList），需与 EntryList 唤醒的线程、新尝试加锁的线程一起，通过非公平锁机制重新竞争 Monitor 锁，并非唤醒后立刻获得锁。

park unpark 原理

每个线程都有自己的一个 Parker 对象，由三部分组成 _counter，_cond 和 _mutex

打个比喻：

• 线程就像一个探险者，Parker 就像他随身携带的急救包，条件变量就好比急救包里的隔离舱。_counter 就好比急救包里的解毒丸（0 为无解毒丸，1 为有解毒丸）

• 调用 park 就是检查探险者是否中毒，是否需要进入隔离舱：

  • 如没有解毒丸（cr=0），说明探险者已中毒，只能钻进隔离舱休息（线程阻塞）

  • 如有解毒丸（c=1），说明探险者未中毒，直接消耗掉解毒丸，继续前进（线程不阻塞）

• 调用 unpark，就好比给急救包补充一颗解毒丸：

  • 如果这时探险者还在阻塞状态，就立刻唤醒他，让他消耗解毒丸后线程恢复运行。

  • 如果这时探险者还未阻塞，那么下次他调用 park 检查中毒时，会直接消耗掉这颗解毒丸，无需进入阻塞状态，继续前进

    • 急救包的空间有限，多次调用 unpark 也只会补充一颗解毒丸（c最多为 1，不累加）

---

1. 当前线程调用 Unsafe.park() 方法

2. 检查 _counter，本情况为 0，这时，获得 _mutex 互斥锁

3. 线程进入 _cond 条件变量阻塞

4. 设置 _counter = 0

---

1. 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1

2. 唤醒 _cond 条件变量中的 Thread_0

3. Thread_0 恢复运行

4. 设置 _counter 为 0

---

1. 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1

2. 当前线程调用 Unsafe.park() 方法

3. 检查 _counter，本情况为 1，这时线程无需阻塞，继续运行

4. 设置 _counter 为 0

---

感谢大家的阅读！🌹