偏向锁默认延迟4秒生效，由-xx:biasedlockingstartupdelay=4000控制，旨在避开jvm启动期高竞争阶段；jdk 15+已彻底移除该功能。
偏向锁默认延迟4秒才生效，不是bug是设计
Java应用刚启动时，synchronized块看似没走偏向锁路径，不是你写错了，也不是JVM抽风——HotSpot默认在启动后延迟4秒才启用偏向锁机制。这个延迟由-XX:BiasedLockingStartupDelay=4000控制，目的是避开JVM自身初始化阶段的同步竞争。
- JVM启动时，GC线程、JIT编译器、类加载器等内部线程会密集使用
synchronized，这些场景天然不满足“单线程长期持有”的偏向前提 - 如果一上来就开偏向锁，这些内部竞争会反复触发“撤销→升级”，造成大量
biased lock revocation开销，反而比直接走轻量级锁更慢 - 延迟不是为了“等系统稳”，而是等JVM度过高竞争的“安全点风暴期”，之后新分配的对象才进入可偏向状态
怎么确认你的锁到底有没有偏向？别猜，看诊断输出
光看代码逻辑没法判断偏向锁是否命中，必须依赖JVM运行时反馈。最直接的方式是加诊断参数，让JVM把锁状态变化打出来：
- 启动命令加：
-XX:+UnlockDiagnosticVMOptions -XX:+PrintBiasedLockStats -XX:+PrintSafepointStatistics - 关键看日志里有没有
Revoked bias of object或Biased lock revocation count持续上涨——说明正在频繁撤销 - 对象创建后立刻加锁（比如在
main方法开头就synchronized(new Object())），大概率不会偏向；睡5秒再锁，才可能看到anonymously biased标记
想跳过延迟？可以，但得清楚代价
用-XX:BiasedLockingStartupDelay=0确实能立刻启用偏向锁，但不是所有场景都适合：
- 适用于：明确知道业务线程模型高度串行（如单线程EventLoop + 大量复用对象）、且JVM启动后无批量类加载/反射调用的服务
- 不适用：Spring Boot类多、启动期大量
synchronized静态块、或用了Lombok @Data（隐式调用hashCode()）的应用——后者会直接禁用偏向锁 - 注意：
hashCode()一旦被调用，对象头Mark Word就被写入哈希值，永久失去偏向资格，这个坑比延迟更隐蔽
JDK 15+ 默认关闭，老配置可能完全失效
如果你用的是JDK 15或更新版本（比如JDK 21），-XX:+UseBiasedLocking这个参数本身已被移除，强行加上只会报Unrecognized VM option错误。
立即学习“Java免费学习笔记（深入）”；
- JDK 15起，偏向锁功能被彻底废弃，HotSpot不再维护相关逻辑
- 不是“默认关”，而是“代码删了”——所以别再查文档找怎么开启，它已经不存在了
- 替代方案只有两个方向：要么接受轻量级锁的CAS开销（现代CPU上差距已不大），要么重构为无锁结构（如
LongAdder、StampedLock）
真正容易被忽略的，不是“怎么开延迟”，而是“要不要开”。很多团队还在调优JDK 8的偏向锁参数，却没意识到线上服务早已升到JDK 17+，那些配置早就没用了。
