Java可重入锁：递归加锁原理解析

Java的可重入锁（如synchronized和ReentrantLock）通过线程私有的持有计数器实现“同一线程多次加锁不阻塞、计数增减、归零才释放”的机制，使其在递归调用中天然避免死锁——但这绝不意味着可以高枕无忧：synchronized由JVM自动保障加解锁平衡，而ReentrantLock需严格手动配对且异常路径稍有疏漏就会导致锁泄漏；更深层的风险在于递归深度失控引发栈溢出或计数器溢出、锁粒度过粗拖垮性能、以及人为混淆锁边界和误用tryLock()等陷阱。真正决定递归同步成败的，从来不是锁能否重入，而是开发者对锁生命周期的精准掌控与面向场景的架构权衡。

可重入锁在递归方法里为什么不会死锁

Java 的 ReentrantLock 和 synchronized 都支持可重入，核心是「同一个线程可以重复获取同一把锁」。这背后靠的是锁的持有计数器：每次加锁 +1，每次解锁 -1，只有计数归零才算真正释放。

递归调用时，如果当前线程已持锁，再次进入加锁逻辑（比如递归调用自身），不会阻塞，而是直接更新计数器。这也是为什么写递归同步方法时，synchronized 不会卡住自己。

• 不支持可重入的锁（如早期手写的自旋锁）在递归中必然死锁
• ReentrantLock 的 isHeldByCurrentThread() 可以验证当前线程是否已持该锁
• 计数器是线程私有的，不存在跨线程干扰

ReentrantLock 和 synchronized 在递归场景下的行为差异

两者都可重入，但实现机制和使用约束不同。最常被忽略的是：synchronized 是 JVM 层隐式管理，而 ReentrantLock 要求显式配对 lock() 和 unlock()。

递归深度大时，ReentrantLock 的计数器会累积，若某层忘记 unlock()，会导致锁永远无法完全释放；而 synchronized 由字节码指令保证进出平衡，更“省心”。

• synchronized 方法递归调用：JVM 自动维护锁计数，无需人工干预
• ReentrantLock.lock() 在 try 块内调用，必须在 finally 块中调用 unlock()，否则递归中途异常会导致锁泄漏
• ReentrantLock.getHoldCount() 可查当前线程的持有次数，调试递归加锁时很实用

递归加锁时容易踩的坑

问题往往不出在“能不能重入”，而出在「锁边界」和「异常路径」没理清。尤其当递归逻辑混着 I/O、外部调用或条件分支时，很容易漏掉解锁，或者在不该加锁的地方重复加锁。

• 在递归出口前未检查是否已持锁，盲目调用 lock()，导致计数虚高（虽不报错，但后续 unlock() 次数不够）
• 用 tryLock() 替代 lock() 做递归控制——这是危险操作：tryLock() 不可重入（除非指定 fair = false 且当前线程已持锁），否则第二次调用直接返回 false
• 锁对象不是 final 或被意外共享（比如用 this 作锁，但子类重写了 equals/hashCode，或多个实例误用了同一把锁）

什么时候不该依赖可重入做递归同步

可重入是保障机制，不是设计捷径。如果递归深度不可控（比如树遍历无剪枝、用户输入触发无限展开），即使锁能重入，也会因栈溢出或锁计数溢出（int 上溢变负）导致行为异常。

• 深度超过千级的递归，优先考虑改用栈结构 + 显式状态管理，而非靠锁重入硬扛
• 锁粒度太大（如整个方法体加锁）会让递归变成串行执行，吞吐骤降，此时应拆解为细粒度锁或无锁结构
• 如果递归中只读不写，用 StampedLock 的乐观读模式比可重入写锁更轻量

可重入性本身很可靠，但人对锁边界的判断，才是递归同步中最难稳住的一环。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java可重入锁：递归加锁原理解析》文章吧，也可关注golang学习网公众号了解相关技术文章。