登录
首页 >  文章 >  java教程

synchronized与ReentrantLock字节码对比解析

时间:2026-04-25 19:22:34 299浏览 收藏

本文深入对比了 Java 中 synchronized 和 ReentrantLock 在字节码层面的本质差异:synchronized 由 JVM 直接通过 monitorenter/monitorexit 指令实现,锁状态隐式存于对象头 Mark Word,无需 Java 方法调用,语义固化且高度优化;而 ReentrantLock 完全基于 Java 层的 AQS 框架和 Unsafe 的 native 操作(如 CAS 和 park),字节码中仅表现为普通方法调用,其灵活性、可中断性、超时机制和可扩展性全部源于显式的代码逻辑——这意味着你看到的字节码只是冰山一角,真正的能力藏在 JVM 实现与 JUC 源码之中,理解这一分野,是掌握并发底层原理的关键突破口。

如何通过分析字节码指令集理解 synchronized 与 ReentrantLock 的底层实现差异

直接看字节码,synchronized 会生成 monitorentermonitorexit 指令,而 ReentrantLock 完全不出现这类指令——它只是普通对象调用,底层靠 Unsafe.park()Unsafe.compareAndSwapInt() 等 JNI 方法配合 AQS 队列实现。

如何用 javap 查看 synchronized 的字节码

写一个最简方法:

public void syncMethod() {
    synchronized(this) {
        count++;
    }
}

编译后执行 javap -v YourClass,关键部分会看到:

  • monitorenter 出现在 synchronized 块入口,对应锁获取
  • monitorexit 出现在块末尾和异常表中(保证无论是否抛异常都会释放)
  • 锁信息不存于 Java 堆,而是记录在对象头的 Mark Word 中,由 JVM 直接管理
  • 没有显式调用任何 Java 方法,也看不到 lock()unlock() 的痕迹

ReentrantLock 的字节码里只有普通方法调用

同样逻辑用 ReentrantLock 实现:

private final ReentrantLock lock = new ReentrantLock();
public void lockedMethod() {
    lock.lock();
    try {
        count++;
    } finally {
        lock.unlock();
    }
}

其字节码中只会看到:

  • invokevirtual 调用 lock.lock()lock.unlock()
  • 没有 monitorenter/monitorexit,也没有任何 JVM 特殊指令参与
  • 真正加锁动作发生在 AbstractQueuedSynchronizer.acquire() 内部,最终落到 Unsafe.compareAndSwapInt()Unsafe.park()
  • 这些是 native 方法,字节码里只体现为 invokenative,无法进一步反编译

为什么 monitorenter 不等于 CAS + park

两者根本不在同一抽象层:

  • monitorenter 是 JVM 规范定义的指令,语义固定:尝试获取对象监视器,失败则挂起线程并进入 Monitor 的 EntryList
  • ReentrantLock 的加锁流程完全在 Java 层建模:先用 CAS 尝试修改 AQS.state,失败则构造 Node 入队,再调用 park() 挂起——这整个过程可被中断、可设超时、可关联多个 Condition
  • JVM 对 monitorenter 的具体实现(如是否自旋、如何调度等待线程)是黑盒;而 ReentrantLock 的每一步都暴露在 Java 代码中,可调试、可扩展
  • 性能差异常被误解:非公平模式下 ReentrantLockcompareAndSwapInt + 快速路径其实比 monitorenter 更轻量;但一旦竞争激烈、需排队,AQS 队列开销就明显高于 Monitor 的原生调度

容易忽略的关键点

仅靠 javap 看不到全部真相:

  • monitorenter 的实际行为依赖 JVM 实现(HotSpot 中已深度优化,比如偏向锁、轻量级锁、重量级锁升级),这些在字节码里毫无体现
  • ReentrantLock 的公平性开关(new ReentrantLock(true))不会改变字节码结构,但会显著改变 AQS 中 tryAcquire 的逻辑分支
  • 所有与线程调度相关的细节(如唤醒策略、park/unpark 配对)必须看 HotSpot 源码或 JUC 源码,字节码本身只是“调用入口”

以上就是本文的全部内容了,是否有顺利帮助你解决问题?若是能给你带来学习上的帮助,请大家多多支持golang学习网!更多关于文章的相关知识,也可关注golang学习网公众号。

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>