synchronized锁升级机制旨在降低锁开销、减少阻塞和上下文切换；轻量级锁通过cas+自旋在多核下提升并发吞吐，偏向锁减少单线程核间干扰，重量级锁则导致多核利用率下降。
synchronized 锁升级机制本身不是为“适配多核处理器”而设计的，而是为**降低锁开销、减少线程阻塞和上下文切换**服务的；但它对多核环境下的性能表现有显著间接影响——关键在于能否让多个线程在低竞争时真正并发执行，而不是被串行化卡住。
轻量级锁与自旋：利用多核空闲周期
当锁处于轻量级状态时，竞争线程不会立即挂起，而是通过 CAS + 自旋（spin）尝试获取锁。这个过程发生在用户态，不触发内核调度，CPU 核心可以持续运行该线程，避免线程切换开销。在多核系统中，自旋线程可独占一个核心短暂等待，而其他线程仍在其余核心上执行，提升了整体吞吐。但自旋不是无限的：JDK 采用自适应策略，根据前一次自旋是否成功动态调整次数，防止过度消耗 CPU。
- 自旋有效前提：临界区短、锁持有时间极短（如简单计数、状态标记）
- 多核优势体现：自旋线程不抢占其他线程资源，也不让出 CPU，适合核间短暂协作场景
- 风险提示：若临界区耗时长，自旋会白耗 CPU 周期，此时 JVM 会快速升级为重量级锁，让线程进入阻塞态
偏向锁：减少单线程场景下的核间干扰
偏向锁本质是“免同步”优化。它假设多数同步块由同一线程反复进入，直接在 Mark Word 中记录线程 ID，后续进入仅做一次 ID 比较（原子读）。这完全规避了 CAS 和内存屏障操作，在单线程或准单线程场景（如 Web 请求链路中的 ThreadLocal 初始化、配置类首次加载）下，能极大降低缓存一致性协议（如 MESI）在多核间的广播压力。
- 多核友好点：无写冲突、无总线争用、不触发缓存行失效（Cache Line Invalid）
- 注意：一旦发生竞争（第二个线程尝试加锁），偏向锁会撤销（revoke）并升级，此过程需 STW 全局安全点暂停，可能影响响应延迟
- JDK 15+ 默认禁用偏向锁，因现代应用更多面向高并发而非单线程热点
重量级锁：多核下的性能拐点
当锁升级为重量级，线程阻塞交由操作系统 Mutex 管理，此时线程从 RUNNING 进入 BLOCKED 状态，被移出 CPU 调度队列。这对多核系统意味着：本可用于并行计算的核，可能因一个慢锁拖累整条流水线。
- 上下文切换代价高：每次阻塞/唤醒涉及用户态→内核态切换，保存/恢复寄存器、栈、TLB 等，消耗数百纳秒至微秒级
- 核利用率下降：多个线程排队等同一把锁，实际只有 1 个核在干活，其余核可能空转或处理无关任务，无法形成有效并行
- 伪共享（False Sharing）风险加剧：重量级锁常伴随频繁的 volatile 写或 monitor enter/exit，易导致相邻变量跨缓存行被反复同步
开发者如何让锁升级更适配多核
锁升级路径（无锁 → 偏向 → 轻量 → 重量）是自动的，但你可以通过代码设计影响其走向：
- 缩小同步粒度：用 synchronized 代码块代替同步方法，只锁必要逻辑，缩短持有时间，提高轻量级锁成功率
- 避免锁对象共享过度：不要用 this 或 Class.class 作为全局锁，改用细粒度对象（如按 key 分段的 Object[] lockArray），分散竞争
- 优先使用无锁结构：对计数、标志位等场景，用 AtomicInteger / LongAdder / StampedLock 读操作，绕过锁升级全过程
- 监控锁状态：通过 -XX:+PrintGCDetails + JFR 或 jstack 查看 BLOCKED 线程数，结合 JOL 工具观察对象头锁标志位，定位是否频繁升级到重量级
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
