偏向锁是JVM为减少单线程反复加锁开销而设计的优化机制，通过对象头Mark Word记录线程ID实现零成本重入，仅在发生竞争时撤销或升级锁。
偏向锁是JVM在无竞争场景下为减少同步开销而设计的一种锁优化机制。它的核心目的不是“防竞争”，而是“省操作”——当一个对象几乎总是被同一个线程反复加锁时，直接跳过所有同步逻辑，让该线程近乎零成本地进入同步块。
偏向锁解决什么问题
在JDK 1.6之前，哪怕只有一个线程反复执行synchronized代码块，每次都要走完整的锁获取流程（比如CAS尝试、检查锁状态等），这会带来不必要的CPU开销和指令路径复杂度。偏向锁把“这个锁大概率只归我用”这一事实提前登记下来，后续访问就变成一次简单的ID比对，连CAS都不需要。
- 避免重复的原子操作（如CAS）
- 消除单线程场景下的锁获取/释放开销
- 降低用户态与内核态切换频率（重量级锁才涉及系统调用）
偏向锁怎么工作的
关键依赖对象头里的Mark Word。当线程第一次获取锁时：
- JVM检测对象处于“可偏向”状态（未锁定、偏向标志位为1、锁标志位为01）
- 用CAS将当前线程ID写入Mark Word，并把锁标记为“已偏向”
- 之后该线程再进同步块，只需读取Mark Word中的线程ID，匹配即通行
整个过程不涉及操作系统互斥量，纯JVM层面完成，所以极快。
立即学习“Java免费学习笔记（深入）”；
偏向锁什么时候会失效
一旦有第二个线程尝试获取同一把锁，偏向锁就必须让位：
- 触发撤销：在安全点暂停原偏向线程，检查其是否存活
- 若原线程已退出或不再持有锁，可重偏向给新线程
- 若原线程仍在运行，则升级为轻量级锁（开始自旋）或直接膨胀为重量级锁
撤销本身有代价——要停线程、遍历栈帧、更新对象头。因此，频繁竞争反而会让偏向锁拖慢性能。
偏向锁适合哪些场景
不是所有同步都适合开启偏向锁。它最有效的情况是：
- 单线程长期持有某对象锁（如单例工具类、线程局部缓存）
- 锁竞争极少，95%以上时间由同一线程访问
- 应用启动后早期阶段（如初始化配置、构建上下文）
像Web请求中每个请求新建对象并短暂加锁、或高频并发修改共享计数器这类场景，偏向锁基本无效，甚至建议用-XX:-UseBiasedLocking关闭。
基本上就这些。偏向锁不是万能钥匙，它是JVM在“大概率单线程”假设下做的性能妥协，理解它的适用边界比记住流程更重要。
