认识 Java 中的锁升级机制

✅ 性能优势：接近无锁，仅首次 CAS 设置偏向，后续零开销。 ❌ 致命缺陷：偏向锁撤销需 Stop-The-World（STW），影响延迟敏感系统。

2. 轻量级锁（Lightweight Locking）—— 低竞争的优雅退让

🔬 底层原理

• 当第二个线程尝试获取已被偏向的锁时，撤销偏向锁
• 线程在栈帧中创建 Lock Record
• 通过 CAS 将对象头 Mark Word 替换为指向 Lock Record 的指针
• 若 CAS 失败，线程自旋重试（默认 10 次），失败则膨胀为重量级锁

🎯 典型场景

• Web 请求处理（低并发、请求串行化）
• 日志写入（多线程交替写，但不同时）

💻 代码示例

@RestController 
public class OrderController { 
    private final Object orderLock = new Object(); 
    @PostMapping("/create") 
    public ResponseEntity<?> createOrder(@RequestBody OrderRequest req) { 
        synchronized (orderLock) { 
            // 多个请求线程交替进入 
            validate(req); 
            return orderService.create(req); 
        } 
    } 
}

✅ 优势：避免线程阻塞/唤醒的系统调用开销（上下文切换成本约 1~10μs） ❌ 风险：自旋浪费 CPU，在 CPU 密集型场景可能恶化性能

3. 重量级锁（Heavyweight Locking）—— 高竞争的最终保障

🔬 底层原理

• 基于 OS Mutex（互斥量） 实现
• 竞争线程被挂起（park()），放入 EntryList 队列
• 持有锁线程释放时，唤醒队列中的一个线程（unpark()）
• 涉及 用户态 ↔ 内核态切换，开销大（约 1~10μs）

🎯 典型场景

• 秒杀库存扣减
• 全局配置更新
• 数据库连接池管理

💻 反面教材 vs 正确做法

// ❌ 反面：synchronized 导致重量级锁竞争 
public class InventoryService { 
    private int stock = 100; 
    public synchronized boolean deduct() { 
        if (stock > 0) { 
            stock--; // 高并发下性能极差 
            return true; 
        } 
        return false; 
    } 
} 
// ✅ 正确：使用 LongAdder（分段无锁） 
public class OptimizedInventory { 
    private final LongAdder deducted = new LongAdder(); 
    private final int totalStock = 100; 
    public boolean deduct() { 
        long current = deducted.sum(); 
        if (current >= totalStock) return false; 
        deducted.increment(); // 无锁，分段累加 
        return true; 
    } 
}

三、生产环境实战：如何应用与调优？

✅ 生产最佳实践

⚙️ JVM 参数调优（生产常用）

# 关闭偏向锁（推荐微服务场景） 
-XX:-UseBiasedLocking 
# 禁用偏向锁延迟（启动即生效） 
-XX:BiasedLockingStartupDelay=0 
# 监控锁统计（诊断用） 
-XX:+PrintBiasedLockingStatistics 
-XX:+UnlockDiagnosticVMOptions 
-XX:+PrintSafepointStatistics 
# 调整自旋次数（谨慎！） 
-XX:PreBlockSpin=15

📌 真实案例： 某电商平台在大促前发现 GC Pause 异常升高，经 JFR 分析发现 偏向锁撤销频繁触发 safepoint。关闭 -XX:-UseBiasedLocking 后，P99 延迟下降 40%。

四、优缺点深度分析

💡 关键洞察： 锁升级是 JVM 的'事后补救'机制。真正的高性能系统应从架构层面避免锁竞争，而非依赖锁优化。

五、实际开发选型策略 —— 高级工程师思维

决策树（体现深度）

(注：原图链接已移除)

🧠 高级建议（面试加分项）

1. 优先无锁：使用 volatile + CAS（如 AtomicReference）

监控锁竞争：使用 Arthas、JFR 分析

# Arthas 查看 BLOCKED 线程 
thread --state BLOCKED 
# JFR 记录锁事件 
java -XX:StartFlightRecording=duration=60s,filename=lock.jfr ...

缩小锁粒度：只锁临界区，而非整个方法

// Bad 
public synchronized void method() { /* ... */ } 
// Good 
public void method() { 
    // 非临界区 
    prepare(); 
    synchronized (this) { 
        // 临界区 
    } 
}

六、面试深度

Q1: 为什么现代微服务要关闭偏向锁？

答：微服务使用线程池复用线程，多个请求线程交替访问同一对象，导致偏向锁频繁撤销。而撤销需触发 safepoint（STW），在高 QPS 下会显著增加 P99 延迟。Kafka、Netty 等高性能框架均默认关闭。

Q2: synchronized 和 ReentrantLock 在 JDK 17 下性能对比？

答：JDK 6+ 对 synchronized 进行了锁消除、锁粗化、锁升级等优化，在低竞争场景性能优于 ReentrantLock（后者始终走重量级路径）。但 ReentrantLock 提供更多功能（超时、公平锁、Condition），适用于复杂同步场景。

Q3: 如何证明锁升级发生了？

答：可通过以下方式验证：使用 JOL（Java Object Layout） 打印对象头开启 JVM 参数 -XX:+PrintBiasedLockingStatistics 使用 JFR（Java Flight Recorder） 记录 Monitor Blocked 事件

总结：高级工程师的并发观

锁升级是 JVM 的'安全网'，但真正的高手从不依赖安全网。应该：

• 理解原理：知道 JVM 如何优化，也知其局限
• 规避竞争：通过无状态设计、分片、异步化减少锁需求
• 工具驱动：用 JFR、Arthas 验证假设，而非猜测
• 权衡取舍：在一致性、性能、复杂度间找到平衡点

'最好的并发控制，是没有并发控制。'
—— 通过架构设计从根本上消灭锁，才是高级工程师的终极追求。