撕开Synchronized的伪装:从对象头到内核态的生死时速

致命卡顿：一次线上P0事故的启示
某电商大促期间，核心下单接口突发周期性卡顿。监控显示：synchronized锁竞争引发70%线程处于BLOCKED状态，最终溯源到商品库存校验段的粗粒度锁使用。这引出一个关键问题：为什么一个Java关键字能让整个应用崩溃？

对象头的秘密：锁的物理载体
每个Java对象头部包含Mark Word（64位JVM中占64bit），其末两位编码锁状态：

|-----------------------------------------------------------------------|
| 锁状态   |     25bit         |     31bit       | 1bit | 2bit |       
|          |（未使用）         |（hashCode等）   | 分代年龄 | 锁标志 |  
|-----------------------------------------------------------------------|  
| 无锁     |                  | hashCode        |      | 01   |  
| 偏向锁   | 线程ID+epoch     |                 |      | 01   |  
| 轻量锁   | 指向栈中锁记录的指针               |      | 00   |  
| 重量锁   | 指向互斥量（mutex）的指针          |      | 10   |  
|-----------------------------------------------------------------------|  

当线程A首次进入同步块时，JVM通过CAS操作将Mark Word中的线程ID替换为A的ID（偏向锁模式），此时锁如同贴上“此路专属”的标签。

锁膨胀：从用户态到内核态的死亡冲刺

1. 偏向锁撤销（Contended Bias）
   当线程B尝试获取已被A偏向的锁时，JVM触发全局安全点暂停，遍历线程栈检测A是否存活：

c++

// hotspot/src/share/vm/runtime/biasedLocking.cpp  
void BiasedLocking::revoke_at_safepoint(Handle h_obj) {  
  if (!h_obj()->mark()->has_bias_pattern()) return;  
  // 遍历所有线程栈检查锁持有者状态  
  Thread::suspend_all_threads();  
  JavaThread* holder = BiasedLocking::get_lock_owner(h_obj());  
  if (holder != NULL) {  
    // 存在竞争则升级为轻量级锁  
    h_obj()->set_mark(markOopDesc::prototype());  
  }  
}  

2. 自旋优化（Adaptive Spinning）
   轻量级锁模式下，线程通过空循环（自旋）尝试获取锁（默认次数由-XX:PreBlockSpin控制）。JDK6引入适应性自旋，根据上次自旋成功率动态调整次数。
3. 内核态阻塞
   当自旋失败且竞争线程数超过CPU核数的一半，锁升级为重量级锁。此时线程通过pthread_mutex_lock进入内核等待队列：

c

// hotspot/src/os/linux/vm/os_linux.cpp  
int os::PlatformEvent::park() {  
  return pthread_cond_wait(_cond, _mutex); // 触发系统调用  
}  

性能悬崖测试数据（4核CPU压测结果）：

开发者避坑指南

1. 锁粒度控制
   错误案例：

java

public synchronized void updateOrder() { // 方法级锁  
   validateStock(); // 耗时10ms  
   calcDiscount(); // 耗时15ms  
   writeDB();      // 耗时20ms  
}  

优化方案：细分锁粒度至库存校验段：

java

public void updateOrder() {  
   synchronized(stockLock) { validateStock(); } // 锁范围缩小80%  
   calcDiscount();   
   synchronized(dbLock) { writeDB(); }  
}  

2. 锁逃逸检测
   通过JVM参数-XX:+DoEscapeAnalysis开启逃逸分析，自动消除无竞态条件的锁（如局部对象同步块）。
3. 替代方案选型
   高并发写场景优先考虑ReentrantLock+Condition组合，其tryLock(timeout)可避免无限阻塞：

java

if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {  
   try { /* 业务逻辑 */ }   
   finally { lock.unlock(); }  
} else {  
   log.warn("获取锁超时，降级处理");  
}  

终极结论
synchronized的本质是用空间换时间的妥协艺术：

• 空间：对象头Mark Word的精心设计
• 时间：从用户态CAS到内核态阻塞的渐进升级
  记住：锁的代价不是获取，而是等待！