偏向锁默认延迟4秒是HotSpot主动设计的冷静期，为避免JVM启动时内置线程频繁争抢撤销偏向锁；JDK 15+起默认关闭，需显式启用-XX:+UseBiasedLocking。
偏向锁默认延迟4秒，不是bug是设计选择
JVM启动后前4秒内新建的对象，不会进入匿名偏向状态，而是保持无锁不可偏向（mark word末三位为001），哪怕你没关-XX:+UseBiasedLocking。这不是配置失效，也不是代码写错了——这是HotSpot的主动规避策略。
原因很实际：JVM自身启动阶段就有大量内置线程（如JIT编译线程、GC线程、Attach Listener等）频繁执行synchronized代码。如果一启动就开偏向锁，这些线程会反复争抢、撤销、重偏向，白白消耗CPU和安全点停顿时间。
所以这4秒是“冷静期”，等系统稳住、业务线程接管后再启用偏向锁。你可以用-XX:BiasedLockingStartupDelay=0强行跳过，但不建议在生产环境这么做。
怎么验证你的对象到底有没有偏向？别信日志，看对象头
光看-XX:+PrintBiasedLockStats输出容易误判，真正靠谱的是直接读对象头。用JOL（Java Object Layout）工具最直观：
- 确保JVM参数含
-XX:+UseBiasedLocking（JDK 15+需显式加，因默认已禁用） - 对象必须在延迟结束后创建（比如
Thread.sleep(5000)之后再new Object()） - 避免调用
hashCode()、wait()、notify()等会破坏偏向状态的操作
示例代码：
Object obj = new Object(); // 确保已过4秒延迟 System.out.println(ClassLayout.parseInstance(obj).toPrintable());
若输出中mark word末三位是101且threadId全0，就是anonymous biased；若末三位是001，说明还没偏向或已被禁用/破坏。
JDK 15+用户注意：偏向锁默认关闭，不是延迟问题
很多开发者调试半天发现“延迟4秒也没用”，结果是根本没启用——从JDK 15起，-XX:+UseBiasedLocking已被默认设为false。你看到的“无锁不可偏向”状态，大概率是因为这个开关根本没打开。
检查方式很简单：
- 运行
java -XX:+PrintFlagsFinal -version | grep UseBiasedLocking - 输出中
bool UseBiasedLocking值为false，就证实了
要恢复偏向锁，必须显式加参数：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0（后者可选，但建议保留4秒延迟）。
什么操作会让偏向锁当场失效？不止是多线程竞争
很多人以为“只要没其他线程来抢，偏向锁就一直稳”，其实还有几个隐蔽杀手：
-
obj.hashCode()：一旦调用，JVM必须把哈希码写进mark word，会清空偏向位，退回到001无锁态 -
obj.wait()：直接升级为重量级锁，偏向信息彻底丢弃 - Full GC：某些GC算法（如CMS早期版本）会在安全点批量撤销所有偏向锁
- 使用
Unsafe.compareAndSwapObject等底层操作：绕过JVM锁机制，可能破坏mark word一致性
这些操作不会报错，但会让后续synchronized直接走轻量级锁路径——性能差异可能在高并发下被放大。
真正难调试的，是那些你以为“只读不改”的代码里悄悄调了hashCode()，比如放进HashSet、打日志时用了toString()（某些实现会触发hash）、甚至Jackson序列化过程……这些地方偏向锁早没了，你还以为它在扛单线程压力。
