偏向锁优化的是单线程重复访问对象时的加锁开销，直接省略CAS等同步操作，仅通过比对Mark Word中的线程ID实现零成本进入临界区。
偏向锁到底在优化什么？
偏向锁不是“加了一把更轻的锁”，而是直接省掉了加锁动作——当一个对象从头到尾只被同一线程访问时，JVM连CAS都不走，只在对象头Mark Word里记下线程ID，后续进入synchronized块时，仅比对ID是否一致就放行。
常见错误现象：VisualVM或jstat显示大量偏向锁撤销（Bias Revocation），GC日志里频繁出现biased_locking_revocation；应用刚启动时吞吐高，几分钟后响应变慢。
- 触发条件：对象未被竞争，且JVM默认开启偏向锁（JDK 1.6+，
-XX:+UseBiasedLocking） - 撤销时机：第二个线程尝试获取该锁时，必须等安全点（safepoint）暂停持有线程，再将锁状态重置为无锁或升级为轻量级锁
- 真实代价：撤销本身要停顿、CAS、清理栈帧里的
Lock Record，比维持偏向锁还贵——所以高并发短生命周期对象（如循环内新建的ArrayList）反而不该用偏向锁 - 实操建议：Web服务类应用（线程复用、对象短暂）可考虑关闭：
-XX:-UseBiasedLocking；科学计算/批处理类长任务若单线程主导，保留即可
轻量级锁怎么自旋？失败了会立刻挂起吗？
轻量级锁本质是“用户态抢锁”：线程在自己栈帧里建一个Lock Record，用CAS把对象头Mark Word替换成指向这个记录的指针。成功=拿到锁；失败=说明别人正抢着，那就自旋等待，不进内核态。
常见错误现象：CPU使用率飙升但请求吞吐没涨，线程堆栈里大量Unsafe.park没出现，却卡在os::PlatformEvent::park附近；jstack看到一堆线程处于RUNNABLE但实际没干活。
- 自旋不是固定10次：JVM根据该锁的历史自旋成功率动态调整，可通过
-XX:PreBlockSpin设初始值（默认10），但实际运行中会浮动 - 自旋失败不等于立刻升级：只有当自旋超阈值、或检测到锁被长时间持有（如临界区含I/O）、或系统负载高时，才升级为重量级锁
- 关键陷阱：自旋期间线程仍占CPU，若临界区本身耗时（比如调用
Thread.sleep(100)或System.out.println），等于白烧CPU——轻量级锁只适合毫秒级、纯内存操作 - 实操建议：避免在
synchronized块里做任何可能阻塞或耗时的操作；用java -XX:+PrintSynchronizationStatistics可观察自旋失败次数
重量级锁升级后，线程到底卡在哪？
一旦升级到重量级锁，对象头Mark Word就不再存线程ID或栈指针，而是指向一个操作系统级的Monitor结构体，里面包含等待队列（EntryList）、阻塞队列（WaitSet）和互斥量（Mutex）。这时抢不到锁的线程真·被OS挂起，从RUNNABLE变成BLOCKED。
常见错误现象：jstack输出里大量线程停在at java.lang.Object.wait(Native Method)或at java.lang.Thread.sleep(Native Method)下方，但真正卡点是at java.lang.Object.<init>(Object.java:xxx)</init>之后的monitorenter指令；监控看到线程数稳定但QPS掉一半。
- 升级不可逆：轻量级锁能升重量级，但重量级锁不会降回去——哪怕之后只剩一个线程访问，它还是得走
Monitor路径 - 内核态切换开销大：每次
park/unpark都涉及用户态→内核态→用户态，还会清空CPU缓存行（cache line），多核环境下尤其伤 - 真实瓶颈常不在锁本身：比如100个线程争同一把锁，但真正导致升级的是其中某个线程持有锁200ms（因DB查询慢），其余99个全被拖进重量级队列
- 实操建议：用
jcmd <pid> VM.native_memory summary查Internal内存增长，确认是否Monitor结构体堆积；用arthas watch跟踪synchronized块执行时长，定位长持有者
怎么验证锁到底升到哪一级了？
别猜，直接看对象头。JDK自带工具jol（Java Object Layout）能打印任意对象的内存布局和Mark Word二进制值，结合锁标志位定义就能反推状态。
常见错误现象：用Unsafe.compareAndSwapInt手动模拟锁逻辑，结果发现行为和synchronized不一致；或者用String字面量当锁对象，发现永远不升级——因为字符串常量池对象默认禁用偏向锁。
-
Mark Word最后2位决定锁状态：01=无锁/偏向锁（看第3位偏向标志），00=轻量级锁，10=重量级锁 - 示例命令：
java -jar jol-cli.jar internals java.lang.Object，输出里找hash: 0x00000000那行，后面跟着的64位十六进制就是Mark Word - 注意陷阱：对象必须已触发过同步（至少执行一次
synchronized(obj)），否则始终显示无锁；数组对象默认不启用偏向锁 - 实操建议：测试阶段加JVM参数
-XX:+PrintBiasedLockingStatistics -XX:+UnlockDiagnosticVMOptions，启动后执行几次同步，再用jstat -biasedlocking <pid>看统计
锁升级不是黑盒策略，而是JVM根据对象使用模式做的实时适配。真正难的不是理解状态流转，而是在压测时从Mark Word变化、线程状态、GC日志三处交叉印证，找出那个让轻量级锁反复失败的临界点。
