可重入锁在递归中不会死锁，因其通过线程私有计数器实现：同一线程重复加锁仅计数+1，解锁-1，归零才释放；synchronized由JVM自动管理，ReentrantLock需显式配对lock/unlock并注意异常路径。
可重入锁在递归方法里为什么不会死锁
Java 的 ReentrantLock 和 synchronized 都支持可重入，核心是「同一个线程可以重复获取同一把锁」。这背后靠的是锁的持有计数器：每次加锁 +1，每次解锁 -1，只有计数归零才算真正释放。
递归调用时，如果当前线程已持锁，再次进入加锁逻辑（比如递归调用自身），不会阻塞，而是直接更新计数器。这也是为什么写递归同步方法时，synchronized 不会卡住自己。
- 不支持可重入的锁（如早期手写的自旋锁）在递归中必然死锁
-
ReentrantLock的isHeldByCurrentThread()可以验证当前线程是否已持该锁 - 计数器是线程私有的，不存在跨线程干扰
ReentrantLock 和 synchronized 在递归场景下的行为差异
两者都可重入，但实现机制和使用约束不同。最常被忽略的是：synchronized 是 JVM 层隐式管理，而 ReentrantLock 要求显式配对 lock() 和 unlock()。
递归深度大时，ReentrantLock 的计数器会累积，若某层忘记 unlock()，会导致锁永远无法完全释放；而 synchronized 由字节码指令保证进出平衡，更“省心”。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
-
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的乐观读模式比可重入写锁更轻量
可重入性本身很可靠，但人对锁边界的判断，才是递归同步中最难稳住的一环。
