synchronized可重入本质是JVM通过锁对象的持有线程ID和重入计数器实现：同一线程每获取一次锁，计数器加1；每次退出同步块或方法减1；仅当计数器归零才真正释放锁。

synchronized 支持可重入，本质是靠锁对象内部的计数器和持有线程 ID 实现的：同一个线程每获取一次锁，计数器加 1；每次退出同步块或方法，计数器减 1；只有计数器归零时，锁才真正释放。

可重入发生的典型场景

只要锁对象一致，以下情况都属于可重入：

• 同步实例方法中调用本类另一个 synchronized 实例方法（锁对象都是 this）
• 同步静态方法中调用本类另一个 synchronized 静态方法（锁对象都是当前 Class 对象）
• synchronized(this) 代码块内嵌套另一个以 this 为锁的 synchronized 代码块
• 递归调用被 synchronized 修饰的方法（如 methodA 内部再次调用 methodA）

为什么必须可重入

不可重入会导致自己卡死自己：

• 比如更新密码方法和校验密码方法都加了 synchronized，而更新逻辑里必须先校验——若不可重入，线程刚拿到锁就进不去校验方法，直接死锁
• 父子类继承中，子类 synchronized 方法调用 super.method()，若不可重入，父类方法拿不到同一把锁，也会阻塞

底层怎么做到不冲突

JVM 为每个锁对象维护两个关键信息：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

立即学习“Java免费学习笔记（深入）”；

• 持有线程 ID：记录当前哪个线程持有该锁
• 重入计数器（recursions）：该线程第几次进入，不是简单“有/无锁”二值判断

当线程再次请求同一把锁时，JVM 只需比对线程 ID 是否匹配，匹配就只增计数器，不阻塞；释放时只减计数器，等归零才清理锁状态。

和 ReentrantLock 的对比提示

两者都支持可重入，但机制不同：

• synchronized 是隐式实现，由 JVM 在字节码层面通过 monitorenter/monitorexit 指令控制计数器
• ReentrantLock 是显式实现，可通过 getHoldCount() 直接读取当前重入次数
• 它们都遵循“同一线程多次获取 → 计数累加；逐次退出 → 计数递减；归零释放”的统一逻辑