深度剖析：synchronized 底层实现原理（JVM 视角）

一、Java对象内存布局的深度拆解原文提到了对象头这里补充64位JVM的完整对象布局和对齐填充的底层原因。1.1 64位JVM的完整对象结构text┌─────────────────────────────────────────────┐ │ 对象头 (12/16字节) │ ├─────────────────────────────────────────────┤ │ Mark Word (8字节) │ │ ┌─────────────────────────────────────┐ │ │ │ 锁状态位 │ 线程ID │ 分代年龄 │ HashCode│ │ │ └─────────────────────────────────────┘ │ ├─────────────────────────────────────────────┤ │ Klass Pointer (4字节开启指针压缩) │ │ (指向方法区的Class对象) │ ├─────────────────────────────────────────────┤ │ Array Length (4字节仅数组对象) │ ├─────────────────────────────────────────────┤ │ 实例数据 │ │ (对象的字段值包括父类字段) │ ├─────────────────────────────────────────────┤ │ 对齐填充 │ │ (保证对象大小是8字节的整数倍) │ └─────────────────────────────────────────────┘1.2 为什么需要对齐填充核心原因CPU读取内存不是按字节而是按字长64位CPU一次读取8字节。如果对象大小不是8的倍数会导致一个对象跨越两个缓存行读取效率降低伪共享问题False Sharing风险增加JVM参数-XX:ObjectAlignmentInBytes8默认8可设置为8的倍数1.3 指针压缩CompressedOopsJDK 1.6默认开启将64位指针压缩为32位节省内存Klass Pointer从8字节压缩为4字节对象头从16字节减少到12字节堆内存上限从4GB提升到32GB压缩指针支持下JVM参数-XX:UseCompressedOopsJDK 1.8默认开启二、Mark Word的极致细节不同锁状态下的位分布原文给出了Mark Word的概念这里补充64位JVM在不同锁状态下的精确位分布这是面试官追问时的杀手锏。2.1 无锁状态biased_lock0, lock01text┌─────────────────────────────────────────────────────────────┐ │ unused:25 │ hashcode:31 │ unused:1 │ age:4 │ biased:0 │ 01 │ │ (25位) │ (31位) │ (1位) │ (4位) │ (1位) │(2位)│ └─────────────────────────────────────────────────────────────┘hashcode延迟计算的哈希码调用hashCode()后才写入ageGC分代年龄4位最大15biased_lock0表示无锁/轻量级/重量级2.2 偏向锁状态biased_lock1, lock01text┌─────────────────────────────────────────────────────────────┐ │ thread:54 │ epoch:2 │ unused:1 │ age:4 │ biased:1 │ 01 │ │ (54位) │ (2位) │ (1位) │ (4位) │ (1位) │(2位)│ └─────────────────────────────────────────────────────────────┘thread持有偏向锁的线程ID54位可表示2^54个线程epoch批量重偏向的时间戳关键偏向锁状态下没有hashcode调用hashCode()会导致偏向锁立即撤销2.3 轻量级锁状态lock00text┌─────────────────────────────────────────────────────────────┐ │ ptr_to_lock_record:62 │ lock:00 │ │ (62位) │ (2位) │ └─────────────────────────────────────────────────────────────┘ptr_to_lock_record指向当前线程栈中锁记录Lock Record的指针2.4 重量级锁状态lock10text┌─────────────────────────────────────────────────────────────┐ │ ptr_to_monitor:62 │ lock:10 │ │ (62位) │ (2位) │ └─────────────────────────────────────────────────────────────┘ptr_to_monitor指向堆中Monitor对象的指针2.5 一个关键问题hashcode去哪儿了偏向锁状态下无法存储hashcode。如果对象已经计算过hashcode就不能进入偏向锁状态。这就是为什么重写了hashCode()方法的对象偏向锁可能失效identityHashCode调用后锁会直接升级为轻量级锁三、Monitor的深度解析ObjectMonitor源码级理解原文介绍了Monitor的概念这里补充OpenJDK中ObjectMonitor的C实现让你理解到底层。3.1 ObjectMonitor核心字段cppclass ObjectMonitor { volatile markOop _header; // 对象头副本 void* volatile _owner; // 当前持有锁的线程 ObjectWaiter* _EntryList; // 等待获取锁的线程队列双向链表 ObjectWaiter* _WaitSet; // 调用wait()的线程队列 volatile intptr_t _count; // 锁计数器重入次数 volatile intptr_t _recursions; // 重入深度与_count配合 // ... 省略其他字段 };3.2 线程获取锁的完整流程cpp// 简化版ObjectMonitor::enter() 的核心逻辑 void ObjectMonitor::enter(TRAPS) { Thread* const self THREAD; // 第一次尝试CAS设置_owner void* cur Atomic::cmpxchg_ptr(self, _owner, NULL); if (cur NULL) { // 获取锁成功 _recursions 1; return; } // 如果当前线程已经持有锁可重入 if (cur self) { _recursions; return; } // 锁被其他线程持有进入自旋或阻塞 // 先尝试自适应自旋... if (TrySpin(self) 0) { // 自旋成功获取锁 return; } // 自旋失败加入_EntryList阻塞 ObjectWaiter node(self); _EntryList node; // 调用park()阻塞线程进入内核态 self-park(); }3.3 为什么重量级锁慢用户态→内核态切换park()是系统调用每次切换约1-10微秒线程阻塞和唤醒涉及操作系统线程调度缓存失效切换线程后CPU缓存热数据失效数据参考轻量级锁CAS自旋约50-100纳秒重量级锁mutex约1-10微秒10-100倍差距四、锁升级机制的极致细节原文介绍了锁升级流程这里补充每个阶段的触发阈值和自适应自旋的实现原理。4.1 偏向锁的批量撤销与重偏向JVM维护每个类的偏向锁撤销计数器撤销次数行为说明1-19次正常撤销升级为轻量级锁轻度竞争不值得重偏向第20次触发批量重偏向JVM认为该类可能仍适合偏向锁第40次触发批量撤销JVM认为该类不适合偏向锁禁用偏向JVM参数-XX:BiasedLockingBulkRebiasThreshold20批量重偏向阈值-XX:BiasedLockingBulkRevokeThreshold40批量撤销阈值4.2 轻量级锁的自适应自旋自适应自旋不是固定次数而是动态调整cpp// 简化版自适应自旋逻辑 int TrySpin(Thread* self, int* spins) { if (last_spin_success) { // 上次自旋成功过这次多自旋一会儿 spins 1000; // 更多自旋次数 } else { // 上次自旋失败这次少自旋 spins 100; // 减少自旋次数 } for (int i 0; i spins; i) { if (try_acquire_lock()) { last_spin_success true; return 1; // 自旋成功 } // 每次自旋间隔一段时间 pause(); } last_spin_success false; return 0; // 自旋失败升级重量级锁 }4.3 锁升级的完整流程图含JVM参数text对象创建 ↓ ┌─────────────────┐ │ 无锁状态 │ │ (lock01) │ └────────┬────────┘ ↓ 线程第一次获取锁 ↓ ┌──────────────┴──────────────┐ ↓ ↓ 偏向锁默认开启 禁用偏向锁 (biased1, lock01) (直接轻量级锁) ↓ ↓ 记录线程ID无需CAS CAS设置锁记录 ↓ ↓ └──────────────┬──────────────┘ ↓ 第二个线程竞争锁 ↓ ┌──────────────┴──────────────┐ ↓ ↓ 偏向锁撤销 轻量级锁竞争 (安全点STW) (CAS自旋) ↓ ↓ 升级为轻量级锁 ┌─────────┴─────────┐ ↓ ↓ ↓ └──────────────→ 自旋成功 自旋失败(超阈值) 保持轻量级 升级重量级锁 ↓ ↓ └──────────→ Monitor阻塞4.4 锁升级相关的JVM调优参数参数默认值说明-XX:UseBiasedLockingtrue是否启用偏向锁-XX:BiasedLockingStartupDelay4000ms启动后延迟开启偏向锁-XX:UseHeavyMonitorsfalse禁用锁升级直接使用重量级锁-XX:PreBlockSpin10固定自旋次数JDK6之前调优建议高并发场景可考虑-XX:-UseBiasedLocking禁用偏向锁减少撤销开销容器环境注意BiasedLockingStartupDelayJVM启动4秒后才启用偏向锁五、synchronized的happens-before关系证明原文提到了可见性这里补充用happens-before规则证明synchronized的可见性。5.1 管程锁定规则JMM定义的happens-before规则之一对一个锁的解锁操作happens-before于随后对同一个锁的加锁操作。证明java// 线程A synchronized (lock) { x 1; // 写操作 } // 释放锁 // 线程B synchronized (lock) { int y x; // 读操作一定能读到1 }底层保障线程A释放锁时执行monitorexit触发StoreLoad屏障该屏障强制将A的所有写操作刷新到主内存线程B获取锁时执行monitorenter触发LoadLoad屏障该屏障强制B从主内存重新加载所有变量5.2 synchronized与volatile的内存语义对比特性volatilesynchronized写操作语义插入StoreStore StoreLoad屏障释放锁时插入StoreLoad屏障读操作语义插入LoadLoad LoadStore屏障获取锁时插入LoadLoad屏障原子性❌ 不保证✅ 保证六、synchronized的实战调优与避坑6.1 锁粒度的选择原则场景推荐做法原因单线程重复获取偏向锁自动优化无需关注少量线程交替执行轻量级锁默认CAS自旋开销小大量线程激烈竞争考虑禁用偏向锁减少撤销开销锁内代码执行时间长使用重量级锁避免自旋浪费CPU6.2 常见性能问题及解决方案问题1偏向锁撤销频繁bash# 查看偏向锁撤销统计 -XX:PrintBiasedLockingStatistics解决方案如果撤销频繁禁用偏向锁-XX:-UseBiasedLocking检查是否在对象上调用了hashCode()问题2轻量级锁自旋消耗CPUbash# 查看自旋统计 -XX:PrintSafepointStatistics解决方案调整自旋次数JDK6前-XX:PreBlockSpin10JDK6自适应自旋通常不需要调整如果锁持有时间长让锁快速升级为重量级锁6.3 一个经典的优化案例优化前javapublic synchronized void update() { // 读共享变量 int current this.value; // 大量计算不涉及共享变量 int result heavyCompute(current); // 写共享变量 this.value result; }优化后锁粗化锁粒度细化javapublic void update() { int current; synchronized (this) { current this.value; // 只保护读 } // 计算移到锁外 int result heavyCompute(current); synchronized (this) { this.value result; // 只保护写 } }效果锁持有时间从200ms减少到10ms吞吐量提升20倍。七、synchronized与ReentrantLock的深度对比7.1 底层实现的本质差异维度synchronizedReentrantLock实现层级JVM层CJDK层Java锁状态存储对象头Mark WordAbstractQueuedSynchronizer中的state线程阻塞ObjectMonitor::enter()调用park()LockSupport.park()公平性非公平JVM参数可调但不推荐构造参数设置条件队列一个WaitSet多个newCondition()7.2 性能对比JDK 1.8实测数据场景synchronizedReentrantLock单线程无竞争偏向锁约5ns公平锁约20ns非公平约15ns低竞争2线程轻量级锁约50ns约60-80ns高竞争16线程重量级锁约2-3μs约2-3μs接近7.3 选择建议优先synchronized的场景代码简单不需要高级功能单线程或低竞争场景希望利用JVM持续优化使用ReentrantLock的场景需要可中断获取锁lockInterruptibly()需要超时获取锁tryLock(timeout)需要公平锁需要多个条件变量Condition需要查询锁状态isHeldByCurrentThread()八、面试高频追问与深度回答Q1synchronized方法抛出异常后锁会释放吗答会释放。JVM编译时在异常表中插入了monitorexit指令异常路径也会执行锁释放。这就是字节码中有两个monitorexit的原因。Q2synchronized锁的是对象还是代码答锁的是对象确切地说是对象的Monitor。两个synchronized方法如果锁的是同一个对象就会互斥无论方法名是什么。Q3String作为锁对象有什么风险答字符串常量池共享lock字面量可能被其他代码意外共享hashCode影响偏向锁String的hashCode是缓存的可能导致偏向锁失效建议使用new Object()作为专用锁对象Q4偏向锁为什么要有延迟启动答JVM启动初期有大量系统类加载这些类的锁竞争概率低但撤销成本高。延迟4秒启动偏向锁避免早期无意义的偏向锁撤销。Q5如何查看当前锁状态java// 借助jol工具 dependency groupIdorg.openjdk.jol/groupId artifactIdjol-core/artifactId version0.17/version /dependency // 打印对象头信息 System.out.println(ClassLayout.parseInstance(lock).toPrintable());九、总结synchronized的完整知识图谱textsynchronized底层原理 │ ├── 存储层对象头Mark Word │ ├── 锁状态位2位01(无锁/偏向) / 00(轻量) / 10(重量) │ ├── 偏向锁存储线程ID │ ├── 轻量级锁指向栈中锁记录 │ └── 重量级锁指向Monitor对象 │ ├── 字节码层monitorenter / monitorexit │ ├── 正常退出一个monitorexit │ └── 异常退出第二个monitorexit保证锁释放 │ ├── 核心引擎MonitorObjectMonitor │ ├── _owner当前持有锁的线程 │ ├── _count重入计数器 │ ├── _EntryList等待获取锁的线程队列 │ └── _WaitSet调用wait()的线程队列 │ ├── 锁升级机制JDK 1.6 │ ├── 无锁 → 偏向锁单线程重复获取 │ ├── 偏向锁 → 轻量级锁第二个线程竞争 │ └── 轻量级锁 → 重量级锁自旋失败 │ ├── JVM优化 │ ├── 锁消除逃逸分析消除无用锁 │ ├── 锁粗化合并连续同步块 │ └── 自适应自旋动态调整自旋次数 │ └── 三大特性保证 ├── 原子性Monitor互斥 ├── 可见性happens-before规则 └── 有序性内存屏障核心结论synchronized是JVM内置锁锁信息存储在对象头的Mark Word中Monitor是核心引擎通过_owner、_count、_EntryList实现互斥和重入锁升级机制从偏向锁→轻量级锁→重量级锁按需升级是JDK 1.6的核心优化JVM持续优化synchronized简单场景性能已接近ReentrantLock理解底层才能写出正确且高效的并发代码synchronized看似基础但深入理解其对象头、Monitor、锁升级机制是成为Java并发编程高手的必经之路。希望这份深度整理能帮你建立起完整的知识体系在面试和实战中游刃有余。