可重入锁允许同一线程多次获取同一把锁而不阻塞，依赖owner线程标识和count重入计数器；加锁时判断空闲、自持有或阻塞；count存于对象头（synchronized）、AQS state（ReentrantLock）或Redis Hash中；getHoldCount()可查当前线程重入次数；count减至0才释放锁并唤醒等待线程。
可重入锁的核心在于：**同一个线程可以多次获取同一把锁，而不会被自己阻塞**。这靠的不是“忽略重复请求”，而是有明确的状态记录——关键就是两个变量：持有线程（owner）和重入计数器（count 或 state）。
可重入锁怎么判断是否允许再次加锁？
每次调用 lock() 时，底层会做这几件事：
- 检查当前锁是否空闲（owner == null），是则直接抢占，count 设为 1；
- 检查 owner 是否等于当前线程，是则不阻塞，只将 count + 1；
- 否则（owner 是其他线程），当前线程进入等待队列。
这个判断逻辑发生在加锁入口（如 ReentrantLock#nonfairTryAcquire 或 synchronized 的 monitorenter 指令中），是原子且线程安全的。
重入次数存在哪儿？怎么查？
重入次数不是“额外存”的，它就编码在锁的同步状态里：
- synchronized：隐式维护在对象头的 monitor 中，通过字节码指令 monitorenter/monitorexit 控制计数器增减；无法在 Java 层直接读取，但可通过调试器或 JOL 工具观察对象头变化；
- ReentrantLock：显式使用 AQS 的 volatile int state 字段存储重入次数。state 值即当前重入数（首次 lock → state=1，再 lock → state=2，依此类推）；
-
Redisson 分布式锁：用 Redis 的 Hash 结构，key 是锁名，field 是客户端唯一标识（如 UUID:threadId），value 就是重入次数；可用
HGET lock:order UUID:123查看。
怎么安全地获取当前重入次数？
Java 标准库提供了公开 API：
- 对 ReentrantLock，调用
getHoldCount()方法，返回当前线程对该锁的持有次数； - 注意：该方法只对当前线程有效，其他线程调用会返回 0（因为非持有线程无权查看）；
- 如果想看整个锁的全局状态（比如调试时），需借助
hasQueuedThreads()、isLocked()等辅助方法，但 state 本身不对外暴露读取接口（避免破坏封装性）。
为什么必须 count=0 才算真正释放？
这是防止“提前释放”的关键设计：
- 每次 unlock() 只做 count - 1；
- 只有当 count 减到 0，才把 owner 置为 null，唤醒等待队列中的下一个线程；
- 这样保证了：lock 和 unlock 必须严格配对，少一次 unlock，锁就一直被占着；多一次 unlock 会抛 IllegalMonitorStateException。
