synchronized通过对象头的Mark Word和Monitor机制实现线程同步。当线程进入synchronized代码块时，需获取对象的Monitor，底层通过monitorenter和monitorexit指令控制，JVM根据竞争状态动态升级锁：从偏向锁（记录线程ID）到轻量级锁（CAS+自旋），再到重量级锁（操作系统互斥量）。锁升级后不可逆，确保高性能与线程安全平衡。synchronized为可重入锁，因Monitor内部维护owner线程和递归计数器，同一线程可多次获取同一锁，计数器递增，退出时递减，归零才释放，避免自阻塞与死锁。
synchronized 的底层实现主要依赖于 Java 对象的对象头（Object Header）中的 Mark Word，以及 JVM 内部的 Monitor 机制。它通过控制线程对共享资源的访问，确保同一时间只有一个线程可以执行特定的代码块或方法，从而实现线程安全。
解决方案
synchronized 的核心在于它的监视器（Monitor）概念。每个 Java 对象都可以关联一个 Monitor。当一个线程试图访问被 synchronized 关键字修饰的代码块或方法时，它必须首先获取到对应对象的 Monitor。如果Monitor已被其他线程持有，当前线程就会被阻塞，直到Monitor被释放。
从字节码层面看，synchronized 代码块通过 monitorenter 和 monitorexit 指令来实现。monitorenter 指令在进入同步块时尝试获取对象的Monitor，monitorexit 则在退出同步块时释放Monitor。为了确保即使在异常情况下也能释放锁，monitorexit 指令通常会有两个：一个正常退出路径，一个异常退出路径。
JVM 内部对 synchronized 的实现进行了优化，引入了锁升级机制：偏向锁、轻量级锁和重量级锁。这种设计是为了在不同并发程度下提供最佳性能。
synchronized 是如何实现线程同步的？
要理解 synchronized 如何实现线程同步，我们得从 Java 对象的内存布局说起。每个 Java 对象在堆内存中都有一个对象头（Object Header），这个对象头可不简单，它包含了运行时类型信息、哈希码，以及最重要的——锁状态信息。这些锁状态信息就存储在对象头里的一个叫 Mark Word 的区域。
当一个线程执行到 synchronized 修饰的代码块或方法时，它会尝试去获取该对象关联的 Monitor。这个 Monitor 可以看作是一个特殊的同步工具，它会记录当前哪个线程持有锁，以及有多少个线程在等待这个锁。
具体过程是这样的：当线程A首次尝试进入同步区域时，它会去修改对象头中的 Mark Word，将自己的线程ID记录进去，表示它现在是这个对象的“锁主”。如果线程B也想进入这个同步区域，它会发现 Mark Word 已经被线程A占用了，那么线程B就得老实地等待，直到线程A释放锁。
整个过程由 JVM 运行时管理，它在底层利用操作系统提供的互斥量（Mutex）或者更轻量级的自旋（Spin-lock）来实现。但对于我们开发者而言，只需要理解它提供了一个简单、可靠的同步机制，避免了多线程并发访问共享资源时可能出现的数据不一致问题。它把很多复杂的底层细节都封装起来了，让我们能专注于业务逻辑。
synchronized 锁升级机制是怎样的？
这部分是 synchronized 性能优化的核心，也是 HotSpot JVM 的一个亮点。JVM 并没有让 synchronized 一开始就很“重”，而是根据实际的竞争情况，动态地调整锁的开销。我个人觉得，这种设计哲学非常务实，毕竟大多数时候，锁可能根本就没有竞争，或者只有同一个线程反复获取。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
偏向锁（Biased Locking）:
- 这是最轻量级的锁。当一个线程第一次访问同步块时，JVM 会在 Mark Word 中记录下这个线程的ID。如果后续还是这个线程来访问，它就不需要再进行任何同步操作，直接进入。这就像给锁“偏向”了第一个访问它的线程，后续这个线程再来，就一路绿灯。
- 它的判断成本极低，就是检查一下 Mark Word 里的线程ID是不是自己。如果不是，或者有其他线程来竞争了，偏向锁就会撤销，升级到轻量级锁。
- 值得注意的是，撤销偏向锁需要暂停持有偏向锁的线程，所以如果锁竞争非常频繁，偏向锁反而会带来性能开销。JVM 默认是开启偏向锁的，但可以通过参数关闭。
-
轻量级锁（Lightweight Locking）:
- 当偏向锁失效（有其他线程来竞争，但竞争不激烈）时，锁就会升级到轻量级锁。
- 线程在自己的栈帧中创建一个锁记录（Lock Record），然后通过 CAS（Compare-And-Swap）操作尝试将对象的 Mark Word 替换为指向这个锁记录的指针。
- 如果替换成功，表示获取锁成功。如果失败，说明有其他线程也在尝试获取锁，此时线程不会立即阻塞，而是会进行自旋（Spin）。它会尝试多次 CAS 操作，希望能在短时间内获取到锁。
- 自旋的目的是避免线程上下文切换的开销。但如果自旋多次仍然没有获取到锁，说明竞争确实比较激烈了，这时轻量级锁就会升级到重量级锁。
-
重量级锁（Heavyweight Locking）:
- 当轻量级锁自旋失败，或者并发竞争非常激烈时，锁就会升级为重量级锁。
- 重量级锁是基于操作系统提供的互斥量（Mutex）来实现的。线程获取不到锁时，会被操作系统挂起（park），进入等待队列。当持有锁的线程释放锁时，会唤醒等待队列中的一个或多个线程。
- 这种方式的开销最大，因为它涉及用户态到内核态的切换，以及线程的上下文切换。这也是为什么我们常说
synchronized是“重量级”锁的原因，但实际上它只有在真正需要时才会变成这样。
整个锁升级过程是不可逆的，一旦升级到重量级锁，就不会再退回到轻量级锁或偏向锁。这个设计哲学就是：根据实际的竞争情况，动态调整锁的粒度和开销，以达到性能和线程安全的平衡。
synchronized 为什么是可重入锁？
可重入性是 synchronized 的一个非常重要的特性，它意味着一个线程在获取了某个对象的锁之后，可以再次获取这个对象的锁，而不会被自己阻塞。这在实际编程中非常有用，尤其是在有方法调用层级关系的同步代码中。
举个例子，假设你有一个类，里面有两个同步方法 methodA() 和 methodB()，并且 methodA() 内部又调用了 methodB()：
class MyService {
public synchronized void methodA() {
System.out.println(Thread.currentThread().getName() + " 进入 methodA");
methodB(); // 内部调用另一个同步方法
System.out.println(Thread.currentThread().getName() + " 退出 methodA");
}
public synchronized void methodB() {
System.out.println(Thread.currentThread().getName() + " 进入 methodB");
// 这里可以执行一些操作
System.out.println(Thread.currentThread().getName() + " 退出 methodB");
}
}如果 synchronized 不具备可重入性，那么当线程T执行 methodA() 并获取了 MyService 对象的锁之后，它在调用 methodB() 时会再次尝试获取同一个对象的锁。如果锁是不可重入的，线程T就会发现锁已经被自己持有了，但又无法再次获取，从而导致死锁。
但 synchronized 不会这样。它的可重入性是通过在 Monitor 内部维护一个计数器（通常称为 recursions 或 entry_count）和一个持有者线程的引用（owner 字段）来实现的。
- 当一个线程第一次成功获取 Monitor 时，
owner字段会被设置为该线程的ID，同时recursions计数器会被设置为1。 - 如果同一个线程再次进入同步代码块（例如通过内部调用另一个同步方法），它会发现
owner字段仍然是自己，这时recursions计数器会简单地递增。线程不会被阻塞，而是可以直接进入。 - 每当线程退出一个同步代码块时，
recursions计数器就会递减。只有当recursions计数器归零时，owner字段才会被清空，表示 Monitor 被完全释放，其他等待的线程才有机会获取锁。
这种设计确保了线程在执行同步方法或代码块时，可以自由地调用其他同步方法或访问其他同步代码块，只要它们是同一个对象的锁。这极大地简化了并发编程的复杂性，避免了不必要的死锁情况，也让代码逻辑更加自然。
