Java早期synchronized被称为重量级锁，因其完全依赖操作系统Mutex实现，每次加锁/解锁都需用户态到内核态切换，涉及上下文保存、CPU权限切换、内核调度等高开销操作，且无偏向锁、轻量级锁等优化机制。

Java 早期的 synchronized 被称为重量级锁，根本原因在于它完全依赖操作系统底层的互斥量（Mutex）实现，每次加锁或解锁都必须触发用户态到内核态的切换。

用户态与内核态频繁切换带来高开销

Java 线程映射到操作系统原生线程，当一个线程尝试获取已被占用的 synchronized 锁时，JVM 会调用系统 API 将其挂起；等锁释放后，再唤醒该线程。这两次操作——阻塞和唤醒——都需要：

• 保存当前线程的寄存器状态、栈信息等上下文
• 切换 CPU 执行权限（从用户态进入内核态）
• 在内核中调度、排队、等待资源
• 切换回用户态并恢复上下文

这些步骤涉及大量内存拷贝和 CPU 指令切换，耗时远超简单同步逻辑本身，尤其在锁持有时间很短的场景下，切换成本可能数倍于业务执行时间。

Monitor 完全由操作系统 Mutex 驱动

早期 JVM 中，每个对象的监视器（Monitor）背后就是一个操作系统互斥量。没有优化机制，所有竞争一律走系统调用路径。哪怕只有一个线程反复进入同步块，也重复经历完整加锁流程，无法跳过或缓存状态。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“Java免费学习笔记（深入）”；

缺乏分层应对竞争程度的能力

当时没有偏向锁、轻量级锁等中间形态。无论是否存在竞争、竞争是否短暂、是否仅单线程访问，统一使用最重的方案——即“一刀切”的重量级语义。这种设计忽略了真实应用中大量低竞争甚至无竞争的同步场景，导致整体性能被严重拖累。

直到 JDK 1.6 引入锁升级机制，才通过对象头（Mark Word）动态记录锁状态，在无竞争时用偏向锁“记住”线程 ID，轻度竞争时用 CAS 自旋代替阻塞，真正把开销降了下来。