偏向锁通过仅比对Mark Word中线程ID实现零同步开销：首次获取需1次CAS，后续重入仅1次普通内存读；复用对象头存储信息，全程用户态运行，专优化单线程高频访问场景，JDK15起已移除。
偏向锁通过“只认线程ID、不走同步流程”的方式，把无竞争场景下的加锁开销降到几乎为零。
核心思路：用一次检查替代每次CAS
轻量级锁每次进入同步块都要执行CAS操作——读取Mark Word、比较、写入新值，三步原子指令。而偏向锁在首次获取时做一次CAS记录线程ID；之后同一线程再进，JVM只需比对Mark Word里的线程ID是否匹配，是则直接通行，连CAS都不触发。
- 首次获取：1次CAS（设置线程ID）
- 后续重入：1次普通内存读（查线程ID），无原子操作
- 对比轻量级锁：每次重入都需1次CAS，开销高一个数量级
对象头复用：状态信息就地存储
64位Mark Word中，偏向锁状态下用54位存线程ID、2位存epoch（偏向时间戳）、4位存GC分代年龄、最后2位固定为01（标识偏向+无锁态）。所有信息都在对象头内完成，无需额外内存分配或指针跳转。
- 避免了轻量级锁所需的栈中Lock Record创建
- 绕开了重量级锁必须的Monitor对象分配与内核态切换
- 整个过程纯用户态，无系统调用、无上下文切换
适用边界清晰：专治“单线程高频访问”
它不是万能优化，而是精准针对一类常见模式：比如单例初始化、Builder构建链、线程本地缓存访问等——这些场景中，同一个线程反复进入同一把锁，但几乎从不被其他线程争抢。
立即学习“Java免费学习笔记（深入）”；
- 典型例子：Vector.add()在单线程循环中调用千万次，开启偏向锁可提速约5%
- 一旦第二个线程尝试获取该锁，JVM立即撤销偏向并升级为轻量级锁，不拖慢竞争路径
- 所以它不增加高竞争场景的负担，只在适合的地方悄悄省下开销
启动时机可控：避免默认延迟拖累冷启动
JVM默认延迟4秒才启用偏向锁（-XX:BiasedLockingStartupDelay=4），防止应用刚启动时大量对象被误偏向。若服务要求快速稳定，可设为0：
java -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0 MyApp- 立即对新创建对象启用偏向逻辑
- 适用于微服务、函数计算等短生命周期或强确定性场景
- 注意：JDK 15+已移除该特性，生产环境需确认JDK版本
