偏向锁是jvm自动启用的优化策略，专为单线程反复获取同一锁设计，通过在对象头记录线程id实现零开销重入，无需cas；但因多核高并发下撤销开销大、适用场景减少，jdk15起默认禁用并废弃，jdk17+彻底移除。
Java中synchronized的偏向锁不是一种“手动开启”的功能，而是一种JVM自动启用的优化策略，专为单线程反复获取同一把锁的场景设计。它的核心价值在于：**消除无竞争下的同步开销，连CAS都不需要**。理解它，关键不在怎么“用”，而在清楚它何时生效、何时失效、为何被弃用。
偏向锁到底在优化什么
大多数业务对象在其生命周期中，往往只被一个线程访问（比如某个Service实例的同步方法，始终由同一线程池中的某线程调用）。传统加锁哪怕只是检查状态，也要走原子指令；而偏向锁直接在对象头（Mark Word）里记下线程ID，后续该线程再进同步块，只需比对ID和标志位——一次普通内存读取就完事。
- 适用前提：对象未被其他线程竞争过，且首次获取锁的是同一个线程
- 性能表现：开销趋近于零，远低于轻量级锁的CAS、更远低于重量级锁的系统调用
- 本质目标：把“锁”退化成“身份标记”，而非真正意义上的互斥机制
偏向锁的触发与撤销条件
它不会在对象创建时立刻激活，而是有延迟（默认4秒），避免启动阶段大量对象盲目偏向。一旦触发，流程如下：
- 线程A第一次进入synchronized块 → JVM检测到无锁状态 → 尝试将Mark Word设为偏向锁格式，并写入A的线程ID
- 线程A再次进入 → 检查Mark Word中thread_id是否为自己 → 是，直接执行
- 线程B尝试进入 → 发现已偏向线程A → 触发“偏向撤销”：暂停线程A（安全点），检查A是否还持有锁；若已释放，则将锁升级为轻量级锁；若A仍在执行，则强制升级
- 只要发生一次有效竞争，该对象后续就不再走偏向路径
为什么从JDK 15开始被废弃
偏向锁在现代多核、高并发服务中逐渐暴露短板：
- 撤销成本高：每次竞争都要进入安全点、STW（Stop-The-World），影响GC和响应延迟
- 适用面窄：微服务、异步编程、线程池复用等场景下，“单线程长期持有”越来越少见
- 维护负担重：JVM需额外管理偏向状态、批量重偏向、批量撤销等复杂逻辑
- 实际收益递减：硬件自旋优化、锁粗化/消除等其他优化已覆盖大部分原属偏向锁的收益场景
因此，JDK 15起将其标记为deprecated，JDK 17+默认禁用，未来版本将彻底移除。
开发者需要做什么
绝大多数情况下，你不需要也不应该主动干预偏向锁行为：
- 无需加
-XX:+UseBiasedLocking（新版JVM已忽略或报警告） - 不要依赖“偏向锁一定存在”来设计逻辑，它随时可能被关闭或跳过
- 排查锁性能问题时，优先关注锁粒度、临界区耗时、是否可无锁化（如用CAS、ThreadLocal），而非纠结偏向状态
- 若确需验证锁状态（如教学或调试），可用JOL（Java Object Layout）配合
-XX:-UseBiasedLocking对比对象头变化
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
