synchronized 通过 monitorenter/monitorexit 指令实现，锁信息存于对象头 Mark Word；ReentrantLock 依赖 AQS 和 Unsafe 的 CAS/park 等 native 方法，字节码仅体现为普通方法调用。
直接看字节码，synchronized 会生成 monitorenter 和 monitorexit 指令，而 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 代码中，可调试、可扩展 - 性能差异常被误解：非公平模式下
ReentrantLock的compareAndSwapInt+ 快速路径其实比monitorenter更轻量；但一旦竞争激烈、需排队，AQS 队列开销就明显高于 Monitor 的原生调度
容易忽略的关键点
仅靠 javap 看不到全部真相：
-
monitorenter的实际行为依赖 JVM 实现（HotSpot 中已深度优化，比如偏向锁、轻量级锁、重量级锁升级），这些在字节码里毫无体现 -
ReentrantLock的公平性开关（new ReentrantLock(true)）不会改变字节码结构，但会显著改变 AQS 中tryAcquire的逻辑分支 - 所有与线程调度相关的细节（如唤醒策略、park/unpark 配对）必须看 HotSpot 源码或 JUC 源码，字节码本身只是“调用入口”
