Java中synchronized能重入是因为每个锁对象（monitor）内部维护一个count计数器，线程首次获取锁时count置1，重入时递增、退出时递减，仅当count归零才真正释放锁。
Java中synchronized为什么能重入？靠的是每个锁对象里的count字段
Java里synchronized支持同一线程反复进入同一把锁，不是靠“放行特权”，而是每个锁对象（即monitor）内部维护一个count计数器。线程第一次获取锁时，count从0变成1；再次进入时只加1，不阻塞；退出同步块时减1，直到count归零才真正释放锁。
这个设计意味着：锁的归属权只认线程ID，不认调用次数；只要持有锁的线程自己再进，就无条件允许——这是可重入性的本质。
- 常见错误现象：
IllegalMonitorStateException通常不是因为不可重入，而是调用了wait()/notify()但没在synchronized块里，或Lock对象被误用（比如ReentrantLock没配对lock()/unlock()） - 使用场景：递归方法、模板方法模式（父类同步，子类回调）、AOP代理中重复织入同步逻辑
- 性能影响：计数器操作是原子的，但每次进出仍需CAS更新
count，比无锁开销略高；不过远小于阻塞/唤醒线程的代价
ReentrantLock的getHoldCount()能直接看到当前线程持锁次数
ReentrantLock把可重入性暴露得更直白——它提供getHoldCount()方法，返回当前线程对该锁的持有次数。而synchronized完全隐藏了计数细节，你没法读取或干预。
这带来两个实际差异：
立即学习“Java免费学习笔记（深入）”；
- 调试时，用
ReentrantLock可以打印lock.getHoldCount()确认是否意外多持有了锁（比如异常路径漏了unlock()） -
ReentrantLock支持公平/非公平模式，但公平模式下重入不插队——同一线程重入时仍要排队，这点和synchronized不同（synchronized永远优先让持有者继续） - 参数差异：
ReentrantLock(true)开启公平锁，会降低吞吐量，但避免饥饿；默认false（非公平）更贴近synchronized行为
可重入≠线程安全：锁计数器不管共享变量的可见性
很多人以为“能重入就说明线程安全”，其实不然。可重入性只解决“能不能进”的问题，不解决“进来了看到什么”的问题。
比如一个synchronized方法里修改了某个static变量，另一个线程在非同步代码里读它，依然可能看到旧值——因为没有happens-before保证。
- 容易踩的坑：在重入代码块里依赖未同步的
volatile字段做判断，或误以为多次加锁增强了内存屏障效果 - 正确做法：可重入性 + 正确的同步范围 + 必要的
volatile修饰（如状态标志），三者缺一不可 - 兼容性注意：
synchronized在JVM各版本语义稳定；而ReentrantLock的tryLock(long, TimeUnit)在低版本Android上可能有精度偏差
字节码层面看synchronized怎么记录重入次数
编译后的synchronized方法或代码块，最终由monitorenter和monitorexit指令实现。JVM规范明确要求：每个monitorenter必须对应一次计数器+1，每个monitorexit对应-1；且只有当计数器为0时，才允许其他线程进入。
你可以用javap -v反编译验证：
public void recursive() {
synchronized(this) {
if (depth < 5) {
depth++;
recursive();
}
}
}
你会发现，无论递归几层，字节码里都只有两对monitorenter/monitorexit——JVM在运行时靠锁对象的count字段撑住整个重入链。
复杂点在于：这个count不是Java堆里的普通字段，而是存在对象头的mark word里（偏向锁/轻量级锁状态下复用位域），所以你看不到它，也改不了它。
