锁的本质是控制临界资源的串行访问，核心目标为互斥、可见性与原子性；synchronized基于Monitor和对象头Mark Word实现，锁升级路径为无锁→偏向锁→轻量级锁→重量级锁；ReentrantLock基于AQS实现，支持更多高级特性；锁优化聚焦减少上下文切换，包括偏向锁、轻量级锁自旋、锁消除与粗化。
锁的本质是控制临界资源的串行访问
Java中加锁不是为了“锁住代码”，而是确保多个线程对同一块共享数据（比如一个int变量、一个List对象）的操作不会交错执行。核心目标就三个：互斥（同一时刻只允许一个线程进入）、可见性（一个线程改完，其他线程立刻能看到）、原子性（一连串操作不可被中断）。没有锁，两个线程同时执行 count++，很可能最终只加了1次而不是2次。
synchronized 的底层靠 Monitor 对象和对象头
每个Java对象在HotSpot虚拟机中都有一个“对象头”，其中的Mark Word区域会记录当前锁的状态：无锁、偏向锁、轻量级锁或重量级锁。synchronized 实际上是通过 JVM 内置的 Monitor（监视器）来工作的：
- Monitor 包含 own
er（持有锁的线程）、entry list（等待获取锁的线程队列）、wait set（调用 wait() 后挂起的线程队列）和计数器（支持重入）
- 当线程进入 synchronized 块时，JVM 尝试用 CAS 修改 Mark Word，成功则获得轻量级锁；失败则可能升级为重量级锁，依赖操作系统 mutex
- 锁的升级路径是：无锁 → 偏向锁（单线程反复进入）→ 轻量级锁（少量竞争，自旋等待）→ 重量级锁（高竞争，线程挂起）
ReentrantLock 依赖 AQS 队列同步器实现
ReentrantLock 是 JDK 层面的显式锁，不依赖 JVM 指令，而是基于 AbstractQueuedSynchronizer（AQS） 构建：
- AQS 内部维护一个 volatile int 类型的 state（表示锁状态）和一个双向 FIFO 等待队列
- 调用 lock() 时，线程先尝试 CAS 修改 state；失败则构造 Node 加入队列，并自旋或挂起
- unlock() 则释放 state，并唤醒队列头节点；支持公平/非公平策略、可中断、超时获取、多条件变量（Condition）等高级能力
- 它比 synchronized 更灵活，但需要手动 unlock()，否则容易死锁
锁优化的关键在于减少操作系统介入
真正昂贵的不是“加锁”动作本身，而是线程阻塞和唤醒带来的上下文切换开销。所以 Java 锁机制持续演进的核心逻辑是：
- 偏向锁：假设“锁总被同一个线程多次获取”，首次获取后直接在 Mark Word 记录线程 ID，后续无需同步操作
- 轻量级锁：有竞争但不激烈时，让线程在用户态自旋等待（忙等），避免进内核态挂起
- 自旋 + 适应性：JVM 会根据历史表现动态调整自旋次数，避免空转耗电
- 锁消除与锁粗化：JIT 编译器在运行期识别出不可能存在竞争的锁（如局部变量上的 synchronized），直接移除；或将多个连续的小同步块合并为一个大块
