java中synchronized锁膨胀本质是jvm根据竞争程度动态升级锁状态的过程：偏向锁→轻量级锁→重量级锁，单向不可逆；偏向锁通过线程id比对实现零开销重入，竞争时撤销并升级；轻量级锁依赖cas与自旋避免内核态切换；重量级锁则借助操作系统mutex实现阻塞等待。
Java 中 synchronized 的锁膨胀过程，本质是 JVM 对对象监视器（Monitor）的优化策略，目的是在低竞争场景下避免操作系统互斥量（Mutex）的开销。它不是“先无锁再加锁”，而是根据运行时竞争情况，动态升级锁的状态：**偏向锁 → 轻量级锁 → 重量级锁**。这个过程由 JVM 自动完成，开发者无法手动控制，但理解其机制有助于分析同步性能问题。
偏向锁：无真实竞争时的“免检通道”
偏向锁针对的是“一个线程反复进入同一把锁”的场景。JVM 在对象头 Mark Word 中记录偏向线程 ID 和 epoch（偏向时间戳）。只要该线程再次尝试获取锁，只需比对线程 ID，无需 CAS 操作，几乎零开销。
一旦有其他线程尝试获取该锁（发生竞争），偏向锁就会被撤销（revoke）——触发一次全局安全点（safepoint），将对象恢复为“未锁定”状态，并升级为轻量级锁。注意：偏向锁默认开启（Java 6+），但从 Java 15 开始已默认禁用，因实际应用中多线程竞争较常见，收益有限。
轻量级锁：短时竞争下的自旋等待
当偏向锁被撤销或初始就无偏向时，若线程尝试获取锁，JVM 会把对象头 Mark Word 复制到当前线程的栈帧中作为“锁记录（Lock Record）”，再用 CAS 尝试将对象头替换为指向该锁记录的指针。
如果 CAS 成功，线程获得轻量级锁；失败则说明已有其他线程持有锁，此时进入自旋（spin）——不立即挂起，而是在用户态循环重试获取锁（默认 10 次，可通过 -XX:PreBlockSpin 调整）。自旋成功即获得锁；失败则膨胀为重量级锁。
- 自旋适用于锁持有时间极短、线程切换成本高于等待的场景
- 自旋消耗 CPU，JVM 会根据历史自旋成功率动态调整自旋次数（适应性自旋）
重量级锁：真正依赖操作系统内核的互斥
当轻量级锁自旋失败，或当前已是重量级锁状态，JVM 会将对象头 Mark Word 设置为指向 Monitor 对象的指针。Monitor 是 C++ 实现的、存在于堆中的对象，内部包含：
- _owner：指向持有锁的线程
- _cxq（Contention Queue）：竞争队列，新争抢线程先入此队列
- _EntryList：等待获取锁的线程队列（由 _cxq 转移而来）
-
_WaitSet：调用
wait()后挂起的线程队列
此时线程会调用操作系统 pthread_mutex_lock 等系统调用，进入阻塞（BLOCKED）状态，由内核调度唤醒。这是开销最大、最“重”的锁形态，但也最公平、最稳定。
锁膨胀不可逆，但可批量撤销与延迟启用
锁一旦升级为重量级锁，就不会再降级回轻量级或偏向锁——这是 JVM 的设计选择，避免降级带来的复杂性和额外开销。不过 JVM 提供了一些调控手段：
-
-XX:-UseBiasedLocking：彻底禁用偏向锁（Java 15+ 默认） -
-XX:BiasedLockingStartupDelay=4000：延迟几秒再启用偏向锁，避开类加载初期的假竞争 -
-XX:AutoInlineTimeout=10等参数影响 JIT 编译时的锁消除（Lock Elision），属于更上层的优化
注意：锁膨胀过程发生在对象级别，不同对象的锁状态彼此独立；同一个对象的锁状态只升不降，且仅在安全点检查和升级。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
