• OpenJDK 8中markwrord 内存布局与状态定义
• 偏向锁 (Biased Locking) 的底层行为与系统影响
• OpenJDK 8源码实现剖析
• CPU 核心与内核影响
• 轻量级锁 (Lightweight Locking) 与 CPU CAS 锁总线/缓存行
• OpenJDK 8源码实现剖析
• CPU 核心与内核影响
• 重量级锁 (Heavyweight Locking) 膨胀与 Linux 内核 Futex 协同
• OpenJDK 8源码实现剖析
• CPU 核心与内核影响
• markwrord 状态变化对系统级影响的横向对比

前言

本文旨在记录近期研读Java源码的学习心得与疑难问题。由于个人理解水平有限，文中内容难免存在疏漏，恳请读者不吝指正。

markwrord状态变对CPU核心与Linux内核的影响

OpenJDK 8中markwrord 内存布局与状态定义

在 OpenJDK 8中，markwrord 的结构定义在 src/share/vm/oops/markOop.hpp 中。它是 Java 对象头（Object Header）的核心组成部分，其大小与 CPU 的位数一致（32位或64位）。通过低几位的组合，markwrord 实现了对“无锁”、“偏向锁”、“轻量级锁”、“重量级锁”和“GC标记”五种状态的复用。

以下是 markOop.hpp 中关于 64 位架构下 markwrord 内存布局的源码定义：

// src/share/vm/oops/markOop.hpp

//  64 bits:
//  --------
//  unused:25 hash:31 -->| unused:1 age:4 biased_lock:1 lock:2 (normal object)
//  JavaThread*:54 epoch:2 unused:1 age:4 biased_lock:1 lock:2 (biased object)
//
//  - biased_lock_bits = 1, lock_bits = 2
//  - lock 状态位映射:
//    00 -> Lightweight Locked (轻量级锁)
//    01 -> Unlocked / Biased (无锁或偏向锁，由 biased_lock_bits 进一步区分)
//    10 -> Heavyweight Locked (重量级锁)
//    11 -> Marked for GC (GC 标记清除状态)

class markOopDesc: public oopDesc {
private:
// 返回不带任何锁标记的原始数值
uintptr_t value() const{ return (uintptr_t) this; }

public:
// 状态位常量定义
enum {
    lock_bits                = 2,
    biased_lock_bits         = 1,
    max_hash_bits            = BitsPerWord - lock_bits - biased_lock_bits - 4 - 1, // 64-2-1-4-1 = 56 位 (包含 unused)
    hash_bits                = 31, // 实际 hash 占 31 位
    age_bits                 = 4,
    epoch_bits               = 2
  };

// 状态掩码与位移
enum {
    locked_value             = 0, // 00
    unlocked_value           = 1, // 01
    monitor_value            = 2, // 10
    marked_value             = 3, // 11
    biased_lock_pattern      = 5// 101 (binary)
  };

// 判断当前 markwrord 是否处于偏向锁状态
bool has_bias_pattern() const{
return (value() & (biased_lock_mask_in_place)) == biased_lock_pattern;
  }

// 判断是否是重量级锁
bool has_monitor() const{
return ((value() & monitor_value) != 0);
  }
};

偏向锁 (Biased Locking) 的底层行为与系统影响

偏向锁的目标是解决“无竞争”情况下的单线程锁重入问题。当一个锁对象第一次被某个线程获取时，JVM 会将 markwrord 设为偏向模式，并利用 CAS 将当前线程的 ID 写入 markwrord 中。

OpenJDK 8源码实现剖析

偏向锁的获取逻辑主要在 src/share/vm/runtime/synchronizer.cpp 和平台相关的汇编器（如 src/cpu/x86/vm/macroAssembler_x86.cpp）中。

// src/share/vm/runtime/synchronizer.cpp

void ObjectSynchronizer::fast_enter(Handle obj, BasicLock* lock, bool attempt_rebias, TRAPS){
if (UseBiasedLocking) {
if (!SafepointSynchronize::is_at_safepoint()) {
// 快速路径：尝试获取偏向锁
      BiasedLocking::Condition cond = BiasedLocking::revoke_and_rebias(obj, attempt_rebias, THREAD);
if (cond == BiasedLocking::BIAS_REVOKED_AND_REBIASED) {
return; // 偏向锁获取或重偏向成功，直接返回
      }
    } else {
assert(!attempt_rebias, "can not rebias of safepoint");
      BiasedLocking::revoke_at_safepoint(obj);
    }
  }
// 偏向锁未开启、或获取失败，则进入轻量级锁逻辑
slow_enter(obj, lock, THREAD);
}

在底层 x86 汇编层面，macroAssembler_x86.cpp 中的 biased_locking_enter 负责生成无锁总线消耗的检测指令：

// src/cpu/x86/vm/macroAssembler_x86.cpp

void MacroAssembler::biased_locking_enter(Register obj_reg, Register obj_header_reg,
                                          Register swap_reg, Register tmp_reg,
bool swap_reg_contains_mark,
                                          Label& done, Label* slow_case,
                                          BiasedLockingCounters* counters){
// 1. 检查 markwrord 的低三位是否为 101 (偏向锁标记)
movptr(obj_header_reg, Address(obj_reg, oopDesc::mark_offset_in_bytes()));
movptr(swap_reg, obj_header_reg);
andptr(swap_reg, markOopDesc::biased_lock_mask_in_place);
cmpptr(swap_reg, markOopDesc::biased_lock_pattern);
jcc(Assembler::notEqual, cas_label); // 不是偏向锁，走向轻量级锁 CAS

// 2. 检查偏向锁中的 Thread ID 是否指向当前线程
movptr(swap_reg, r15_thread); // r15 在 x86_64 上存储着当前 JavaThread 指针
xorptr(swap_reg, obj_header_reg);
andptr(swap_reg, ~((int32_t)markOopDesc::age_mask_in_place | markOopDesc::epoch_mask_in_place));
jcc(Assembler::equal, done); // Thread ID 匹配，锁重入成功，完全没有原子指令

// ... 偏向锁撤销或重偏向的慢速路径
}

CPU 核心与内核影响

• CPU 缓存一致性与总线流速：当锁处于偏向状态且未发生竞争时，获取和释放锁的过程不需要执行任何原子汇编指令（如 LOCK 前缀指令）。CPU 核心仅对本核的 L1/L2 Cache 进行常规的 Read/Write 操作。根据 MESI 协议，该缓存行（Cache Line）保持在 Modified (M) 或 Exclusive (E) 状态，不会向内核总线发送无效化（Invalidate）消息，从而避免了缓存行回写与总线交通拥堵。
• Linux 内核影响：完全发生在 JVM 用户态。Linux 内核对此无感知，线程始终处于 TASK_RUNNING 状态，不涉及系统调用与内核调度。
• 全局安全点（Safepoint）代价：如果另一个线程尝试获取已被偏向的锁，JVM 必须撤销（Revoke）偏向锁。偏向锁撤销必须在 Safepoint 下进行。这时，VM 线程会向所有 CPU 核心发送中断信号或设置安全点内存页屏蔽保护，迫使所有 Java 线程进入暂停状态。Linux 内核需要将这些线程的上下文挂起，切换到信号处理或安全点等待逻辑，带来显著的进程级上下文切换开销。

轻量级锁 (Lightweight Locking) 与 CPU CAS 锁总线/缓存行

当偏向锁关闭，或者多个线程交替交替获取锁（无激烈竞争）时，markwrord 会转换为轻量级锁状态。

OpenJDK 8源码实现剖析

轻量级锁的核心在于在当前线程的栈帧（Stack Frame）中创建一个锁记录（BasicObjectLock 中的 BasicLock），并将对象的 markwrord 复制到该锁记录中（称为 Displaced markwrord），然后通过 CAS 将对象的 markwrord 指向该锁记录。

// src/share/vm/runtime/synchronizer.cpp

void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS){
  markOop mark = obj->mark();

if (mark->is_neutral()) { // 如果当前是无锁状态 (001)
// 1. 将原 markwrord 复制到线程栈帧的 Lock Record 中
    lock->set_displaced_header(mark);
// 2. 通过 CAS 尝试将对象头的 markwrord 替换为指向 Lock Record 的指针
if (Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark) == mark) {
return; // CAS 成功，当前线程获取轻量级锁
    }
  } else if (mark->has_locker() && THREAD->is_lock_owned((address)mark->locker())) {
// 3. 如果是当前线程自身的锁重入
    lock->set_displaced_header(NULL); // 压入 NULL 标记，代表重入
return;
  }

// 4. 存在锁竞争，或者锁已被其他线程持有，升级为重量级锁
  lock->set_displaced_header(markOopDesc::unused_mark());
  ObjectSynchronizer::inflate(THREAD, obj())->enter(THREAD);
}

其底层 CAS 最终调用 src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp 中的内联汇编：

// src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp

inline intptr_t Atomic::cmpxchg_ptr(intptr_t exchange_value, volatile intptr_t* dest, intptr_t compare_value){
intptr_t result;
// __asm__ __volatile__ 嵌入汇编，使用 lock cmpxchgq 指令
  __asm__ __volatile__ (LOCK_IF_MP(%4) "cmpxchgq %1,(%3)"
                        : "=a" (result)
                        : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                        : "cc", "memory");
return result;
}

CPU 核心与内核影响

• LOCK 前缀与总线/缓存锁：在现代 Intel/AMD CPU 上，lock cmpxchgq 指令不会无条件锁住物理系统总线。如果目标内存地址（即对象头所在的缓存行）已经缓存在当前 CPU 核心的 L1/L2 Cache 中，CPU 会触发缓存锁定（Cache Locking）。

• MESI 协议与缓存行弹跳（Cache Line Bouncing）：

• 执行 lock cmpxchgq 的 CPU 核心会向内核总线发出 RFO (Request For Ownership) 信号，将其他 CPU 核心中对应的缓存行状态从 Shared (S) 变更为 Invalid (I)。

• 执行核心将自身缓存行状态设为 Modified (M) 并独占写入。

• 如果多个 CPU 核心上的线程频繁交替执行此 CAS 指令，会导致该对象头所在的缓存行在不同的 CPU 核心之间频繁“弹跳”，触发大量的 L1/L2 缓存未命中（Cache Miss）与数据总线同步流量，拖慢 CPU 整体的执行流速。

• Memory Barrier (内存屏障)：LOCK 前缀指令具有隐式的全屏障（Full Barrier）作用，它会刷新 CPU 的 Store Buffer 与 Load Buffer，阻止指令重排。这会导致当前核心的流水线（Pipeline）被强制清空（Flush），暂时阻止了流水线的乱序执行（Out-of-Order Execution）能力。

• Linux 内核影响：依然维持在用户态。虽然 CPU 产生了硬件级别的同步消耗，但由于未调用系统调用，Linux 内核不参与线程调度，上下文切换数（Context Switches）不会增加。

重量级锁 (Heavyweight Locking) 膨胀与 Linux 内核 Futex 协同

当轻量级锁发生竞争，或者 CAS 自旋超时，JVM 会触发锁膨胀（Inflation），将 markwrord 的低两位修改为 10，并将其余位数指向一个多线程同步器——ObjectMonitor 结构体。

OpenJDK 8源码实现剖析

锁膨胀逻辑位于 src/share/vm/runtime/synchronizer.cpp 的 ObjectSynchronizer::inflate：

// src/share/vm/runtime/synchronizer.cpp

ObjectMonitor* ObjectSynchronizer::inflate(Thread * Self, oop object){
for (;;) {
    markOop mark = object->mark();

// 情况 1：已经是重量级锁了，直接返回
if (mark->has_monitor()) {
return mark->monitor();
    }

// 情况 2：正在膨胀中，说明有其他线程在操作，当前线程稍作自旋等待
if (mark == markOopDesc::INFLATING()) {
ReadStableMark(object);
continue;
    }

// 情况 3：当前是轻量级锁，尝试升级为重量级锁
if (mark->has_locker()) {
      ObjectMonitor * m = omAlloc(Self); // 从线程本地或全局队列分配一个 ObjectMonitor
      m->Recycle();
      m->_Responsible  = NULL ;
      m->_recursions   = 0 ;
      m->_SpinDuration = ObjectMonitor::Knob_SpinLimit ; // 设置自旋参数

// 将 markwrord 替换为 INFLATING 状态
      markOop cmp = (markOop) Atomic::cmpxchg_ptr(markOopDesc::INFLATING(), object->mark_addr(), mark);
if (cmp != mark) {
omRelease(Self, m, true);
continue; // CAS 失败，重试
      }

// 填充 ObjectMonitor 的属性
      m->set_header(mark->displaced_header());
      m->set_owner(mark->locker());
      m->set_object(object);

// 最终将对象头的 markwrord 指向 ObjectMonitor，状态位设为 10
      object->release_set_mark(markOopDesc::encode(m));
return m;
    }

// ... 情况 4：无锁状态下的膨胀
  }
}

在获取 ObjectMonitor 时，如果自旋失败，最终会调用 ObjectMonitor::EnterI 并进入操纵系统级别的挂起逻辑：

// src/share/vm/runtime/objectMonitor.cpp

void ObjectMonitor::EnterI (TRAPS){
  Thread * Self = THREAD ;
// ... 尝试自旋获取锁

// 将当前线程封装为 ObjectWaiter 节点，并放入 _cxq 队列
ObjectWaiter node(Self);
  Self->_ParkEvent->Reset() ;
  node._notified = 0 ;
  node.TState    = ObjectWaiter::TS_CXQ ;

  ObjectWaiter * nxt ;
for (;;) {
    node._next = nxt = _cxq ;
if (Atomic::cmpxchg_ptr(&node, &_cxq, nxt) == nxt) break ;
  }

// 阻塞线程的循环
for (;;) {
if (TryLock (Self) > 0) break ; // 再次尝试获取锁

// 真正触发 OS 级别挂起
if ((SyncFlags & 2) && _Responsible == NULL) {
       Atomic::cmpxchg_ptr (Self, &_Responsible, NULL) ;
    }

// 调用 os::PlatformEvent::park() 挂起线程
    Self->_ParkEvent->park() ;

if (TryLock(Self) > 0) break ;
// ... 处理伪唤醒
  }
}

Linux 平台下的 os::PlatformEvent::park() 位于 src/os/linux/vm/os_linux.cpp：

// src/os/linux/vm/os_linux.cpp

void os::PlatformEvent::park() {
int status ;
// 原子操作：将当前状态设为 0（即需要挂起）
if (Atomic::xchg(&_Event, 0) <= 0) {
pthread_mutex_lock(_mutex); // 获取底层的 POSIX 互斥锁
while (_Event < 0) {
// 调用 Linux 线程库的 pthread_cond_wait，底层映射为 Linux 内核的 futex 系统调用
       status = pthread_cond_wait(_cond, _mutex);
     }
pthread_mutex_unlock(_mutex);
  }
}

CPU 核心与内核影响

当轻量级锁升级为重量级锁，或者直接在重量级锁上产生未命中自旋时，系统层面会发生剧烈的震荡：

1. CPU 核心层面的改变

• PAUSE 指令的密集调用：在进入重量级锁的自旋优化（Adaptive Spinning）期间，JVM 会密集执行 PAUSE 汇编指令。PAUSE 通知 CPU 当前处于自旋等待循环，CPU 会暂停流水线中指令的解码，防止因内存依赖性冲突导致处理器在退出循环时清空流水线（Pipeline Flush），大幅降低自旋期间的 CPU 功耗和热量。
• TLB 与 Cache 局部性失效：一旦自旋失败，线程准备挂起，CPU 必须保存当前执行流的寄存器上下文。当线程被唤醒并在另一个 CPU 核心上调度执行时，由于跨核心迁移，新核心的 L1/L2 缓存中完全没有该线程的数据（Cache Cold Start），并且由于进程/线程间地址转换可能带来的快表（TLB）刷新，会导致短期内频繁发生 TLB Miss 和 Cache Miss。

2. Linux 内核层面的改变

• 用户态到内核态的上下文切换（Context Switch）：pthread_cond_wait 触发 sys_futex 系统调用（通过 syscall 指令转换到特权级别 Ring 0）。CPU 核心的堆栈指针从用户栈切换到内核栈，保存通用寄存器群（RAX, RCX, RDI 等）到进程的 pt_regs 结构体。
• 内核 O(1) 锁管理（Futex Hash Bucket）：内核接收到 FUTEX_WAIT 请求后，会根据 _cond 变量的虚拟地址，在内核的 futex_hash_bucket 散列表中计算哈希值，获取对应的平衡二叉树/链表槽位，将当前线程的 task_struct 挂入该哈希桶的等待队列中。
• 状态机转换与进程调度器（Scheduler）介入：
• 内核将该线程的 task_struct->state 状态从 TASK_RUNNING 改为 TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE。
• 调用 schedule() 函数唤醒 Linux 调度器，将其从当前 CPU 核心的运行队列（runqueue）中摘除。
• 调度器选择下一个处于 TASK_RUNNING 状态的最高优先级线程，将其寄存器上下文载入 CPU 核心，完成一次主动上下文切换（Voluntary Context Switch）。

markwrord 状态变化对系统级影响的横向对比

下表总结了从无锁到重量级锁的演进过程中，底层的硬件与内核性能指标变化：