偏向锁在另一线程竞争时触发检查并升级：原线程消亡、调用wait/notify、hashCode或GC发现偏向线程死亡均导致升级，且不会主动释放。
偏向锁什么时候会失效并升级？
偏向锁不是永久有效的，只要出现“另一个线程来竞争”这个事实，它就大概率要升级——但不是立刻升，而是触发一连串检查。关键在于：**偏向锁不会主动释放，所以“竞争”发生时，JVM必须先确认原持有线程是否还活着、是否还在用这把锁**。
常见触发场景包括：
- 第二个线程调用
synchronized(obj)试图进入同一同步块 - 任意线程对已偏向对象调用
obj.wait()或obj.notify()（哪怕还是原线程）→ 直接升级为轻量级锁 - 任意线程调用
obj.hashCode()→ 如果对象正处在偏向状态，强制升级为重量级锁（因为 hashCode 需要存进 Monitor，而偏向锁的 Mark Word 没地方存） - GC 过程中发现偏向线程已消亡，且锁未被释放 → 清空偏向信息，重置为无锁状态，下个竞争者可重新偏向
容易踩的坑：-XX:BiasedLockingStartupDelay=0 必须配 -XX:+UseBiasedLocking 才生效；默认延迟 4 秒，意味着刚启动那几秒你测不到偏向行为，别误判“没开启”。
轻量级锁自旋失败后一定升级为重量级锁吗？
是的，但“失败”的判定比想象中严格：不是某一次 CAS 失败就升级，而是**连续自旋达到阈值（默认 10 次）后仍无法获取锁，才触发升级**。而且 JDK 6+ 默认启用自适应自旋——如果上次在同一个锁上自旋成功了，这次就会多旋几次；反之则可能跳过自旋直接阻塞。
实操建议：
- 可通过
-XX:PreBlockSpin=20调高固定自旋次数（仅 JDK 6~8 有效），但更推荐依赖自适应逻辑 - 若应用大量短临界区 + 高并发争抢（如高频计数器），自旋反而浪费 CPU，此时关闭偏向锁 + 适度调低自旋（或用
ReentrantLock配合tryLock()）更稳 - 注意：轻量级锁解锁时会校验 Mark Word 是否匹配，若不一致（比如被其他线程篡改过），会直接唤醒等待队列，不走正常释放流程
性能影响很实际：自旋期间线程不挂起，但占着 CPU；一旦升级为重量级锁，线程进 Monitor 队列、OS 调度介入、上下文切换开销立刻上来——这就是为什么“锁膨胀”常成为 GC 日志里 BlockingQueue 或 ConcurrentHashMap 初始化阶段的隐形瓶颈。
重量级锁的 Monitor 到底长什么样？
它不是一个 Java 对象，而是 JVM 在对象头外维护的一块 C++ 结构体，包含三个核心字段：_owner（持有线程指针）、_WaitSet（调用 wait() 挂起的线程队列）、_EntryList（正在自旋或阻塞等待锁的线程队列）。一旦锁膨胀到这一步，所有后续竞争都绕不开操作系统线程调度。
关键事实：
- Monitor 是 lazy-initialize 的——只有首次升级时才分配，不是每个对象都有
-
hashCode()和wait()/notify()一定会走到 Monitor，所以它们天然破坏偏向性 - 重量级锁状态下，
synchronized的入口不再是 CAS，而是调用ObjectSynchronizer::enter()，走 OS mutex（如 pthread_mutex_t） - 使用 JOL（Java Object Layout）工具查看对象头，能看到 Mark Word 变成指向 Monitor 的指针，且锁标志位为
010
兼容性提醒：某些老版本 JDK（如 7u40 前）在 CMS GC 下曾有 Monitor 泄漏问题；JDK 8u40 后基本稳定，但若频繁看到 java.lang.Thread.State: BLOCKED (on object monitor) 占比突增，就得查是不是锁粒度太粗或存在隐式锁竞争。
怎么验证当前锁到底处于哪种状态？
不能靠猜，得用工具看 Mark Word。最直接的是用 JOL：new org.openjdk.jol.vm.VM().details() 确认 JVM 参数生效，再用 ClassLayout.parseInstance(obj).toPrintable() 输出对象头十六进制值，对照锁状态位解析。
示例判断逻辑（Mark Word 低 3 位）：
-
001→ 无锁（未锁定，可偏向） -
101→ 偏向锁（thread ID 存在，且偏向位为 1） -
000→ 轻量级锁（指向当前线程栈中 Lock Record 的指针） -
010→ 重量级锁（指向 Monitor 的指针）
容易被忽略的点：JVM 参数 -XX:+PrintSynchronizationStatistics 会输出全局锁统计（如偏向撤销次数），但只在退出时打印；生产环境慎用。真正实用的是配合 jstack -l <pid> 查看线程堆栈中的锁状态描述——里面明确写着 “locked <0x...> (a java.lang.Object)” 还是 “- waiting to lock <0x...>”，后者基本就是重量级锁排队了。
