synchronized 的底层是基于对象监视器（monitor）的同步机制，而非外部监控技术；它由 jvm 原生管理，依赖对象头 mark word 存储锁状态，并通过 monitorenter/monitorexit 指令或 acc_synchronized 标志触发 monitor 竞争，支持无锁→轻量级锁→重量级锁的动态升级路径。
synchronized 的底层不是“监控技术”，而是基于对象监视器（Monitor）的同步机制。它不依赖外部监控系统，而是由 JVM 在运行时直接管理锁状态、线程调度与资源互斥——本质是内置于对象头和字节码中的原生同步设施。
Monitor 是 synchronized 的核心执行单元
每个 Java 对象在创建时都隐式关联一个 Monitor（也叫管程），它是 JVM 层面的同步原语，包含： - 一个持有者（Owner）字段，记录当前占有锁的线程； - 一个进入队列（Entry Set），存放竞争锁失败而被阻塞的线程； - 一个等待队列（Wait Set），存放调用 wait() 后挂起的线程。
当线程执行 monitorenter 指令（同步代码块）或进入带 ACC_SYNCHRONIZED 标志的方法时，JVM 就会尝试获取该对象关联的 Monitor。获取成功则成为 Owner；失败则进入 Entry Set 等待唤醒。
锁状态存在对象头的 Mark Word 中
Monitor 本身不直接存储在堆中，而是通过对象头的 Mark Word 动态指向。Mark Word 是对象内存布局的关键部分，在 64 位 JVM 中占 8 字节，其内容随锁状态变化而复用：
- 无锁状态：存哈希码、GC 年龄、锁标志位（001）；
- 偏向锁：存偏向线程 ID、epoch、锁标志位（101）；
- 轻量级锁：存指向栈中 Lock Record 的指针（00）；
- 重量级锁：存指向堆中 Monitor 对象的指针（10）。
这种设计让锁状态可动态升级，且不额外占用对象空间。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
性能关键在于锁升级路径与 JVM 优化策略
synchronized 的性能并非固定不变，而是取决于实际竞争程度和 JVM 版本的优化能力：
- 低竞争场景（如单线程反复进入）：偏向锁启用时，几乎零开销（仅一次 CAS 设置线程 ID）；
- 中等竞争（少量线程交替执行）：升级为轻量级锁，使用 CAS + 自旋，避免系统调用；
- 高竞争（多线程频繁争抢）：最终升级为重量级锁，依赖操作系统 mutex，触发线程挂起/唤醒，开销显著上升。
JDK 6 起引入的优化还包括：锁消除（逃逸分析发现锁无共享，直接删掉）、锁粗化（合并相邻同步块减少加解锁次数）、自适应自旋（根据历史成功率动态调整自旋时长）。
现代 JDK 中的现实表现
从 JDK 15 开始，偏向锁默认关闭；JDK 18 起彻底移除。这意味着当前主流版本（JDK 17/21）中，synchronized 实际走的是“无锁 → 轻量级锁 → 重量级锁”路径。实测表明：在多数业务场景下（如 Web 请求处理、缓存更新），其性能已接近 ReentrantLock，且无需手动释放，不易出错。
真正影响性能的往往不是 synchronized 本身，而是锁粒度——比如锁整个方法 vs 锁某段临界区，或锁大对象 vs 锁细粒度对象。合理缩小同步范围，比纠结“用不用 synchronized”更能提升并发吞吐。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
