偏向锁被禁用的直接原因是对象头中hashcode占用了mark word的锁状态位，导致偏向锁信息无法写入，二者在31/62位空间内互斥。
偏向锁被禁用的直接原因：对象头中 hashcode 占用了 mark word 的锁状态位
Java 对象在启用偏向锁时，会把线程 ID 直接存进对象头的 mark word。但一旦调用过 System.identityHashCode()（或任何触发 hashcode 计算的操作），JVM 就必须把真实 hashcode 写进 mark word —— 而这个写入会覆盖掉原本留给偏向锁的结构位。
这不是“锁升级”或“竞争导致”，而是底层存储冲突：hashcode 和偏向锁信息共享同一块 31/62 位空间，二者互斥。
-
hashCode()被重写？不影响 —— 只有System.identityHashCode()或未重写的Object.hashCode()才会真正写入对象头 - 哪怕只调用一次
System.identityHashCode(obj)，该对象后续永远无法进入偏向状态 - HotSpot 源码里明确检查
mark_word->has_hash_code()，为 true 就跳过偏向逻辑
哪些操作会悄悄触发 identity hashcode
很多看似无害的代码，实际会强制计算并缓存 identity hashcode，从而“污染”对象的偏向资格：
- 日志打印：
log.debug("obj={}", obj)（SLF4J 默认调用toString()，而默认实现含System.identityHashCode() - 集合查找：
HashSet.contains(obj)、HashMap.get(obj)（即使 key 不是该对象，只要发生哈希计算就可能触发） - 断言或调试：
Objects.requireNonNull(obj, "obj=" + obj)（字符串拼接触发toString()） - JDK 自身：某些
java.util类在扩容、序列化、反射时也会调用System.identityHashCode()
验证对象是否还能偏向：看它有没有被“写过 hash”
不能只看是否调用过 hashCode()，得确认 hashcode 是否已落盘到对象头。最直接的方式是用 JVM 参数 + jol 工具观察对象头布局：
- 启动参数加
-XX:+PrintBiasedLockingStatistics -XX:+UnlockDiagnosticVMOptions，然后跑一段代码，看输出里biased_locks_used是否增长 - 用 JOL（Java Object Layout）：调用
ClassLayout.parseInstance(obj).toPrintable()，如果输出中hash:字段非 0，说明已写入 —— 此时biased_locks_used一定为 0 - 注意：
new Object()刚创建时hash是 0，但第一次调用System.identityHashCode()后，hash变成非零值，且不可逆
想保留偏向锁？得从对象生命周期早期控制 hashcode 生成
不是“避免调用 hashCode()”，而是避免让 JVM 认为“需要持久化这个 hash”。关键在于切断 identity hashcode 的落盘路径：
- 启动时加
-XX:-UseBiasedLocking？不行 —— 这是全局关，不是单对象控制 - 用
-XX:BiasedLockingStartupDelay=0加速偏向，但解决不了已被 hash 的对象 - 真正有效的是：确保对象在首次可能被 hash 前，已被线程成功偏向（即先执行同步块，再做日志/集合操作）
- 更稳妥的做法：对高频并发且需偏向的类，重写
hashCode()返回固定值（如return 1;），绕过System.identityHashCode()调用
偏不偏向，不是由“有没有锁竞争”决定的，而是由“对象头有没有被 hashcode 占领”决定的。一旦被占，连尝试偏向的机会都没有 —— 这点很容易被堆栈里没报错、没警告的日志和集合操作掩盖。
