reentrantlock 无直接判断方法，但可通过 getholdcount() 间接判断：若返回值大于0，说明当前线程持有该锁；为0则未持有；该方法线程安全、仅对调用线程有效，不可用 islocked() 替代。
ReentrantLock 本身没有直接提供“判断当前线程是否持有该锁”的公开方法，但可以通过 getHoldCount() 配合 Thread.currentThread() 间接判断。
使用 getHoldCount() 判断当前线程是否持有锁
ReentrantLock 的 getHoldCount() 方法返回当前线程持有该锁的重入次数（即当前线程已加锁但尚未释放的次数）。若返回值大于 0，说明当前线程正持有该锁；若为 0，则未持有（或根本没加锁）。
- 该方法是线程安全的，只反映调用时的状态
- 仅对当前线程有效 —— 它不会告诉你其他线程是否持有锁，只返回「调用线程」自己的持有计数
- 即使锁是公平锁，此行为也不变
注意：不能用 isLocked() 替代
isLocked() 返回的是「锁是否被任意线程持有」，不区分线程。它无法回答“我有没有锁”，只能回答“锁现在是不是被占着”。例如：
- 线程 A 持有锁 →
isLocked()返回true，getHoldCount()在 A 中返回 >0，在 B 中返回 0 - 锁未被任何线程持有 → 两者都返回
false/0
实际使用示例
常见于可重入逻辑、调试或避免重复加锁的场景：
if (lock.getHoldCount() == 0) {
lock.lock(); // 确保只在未持有时才加锁
}
// ... 执行业务逻辑 ...
if (lock.getHoldCount() > 0) {
lock.unlock(); // 安全释放，避免 IllegalMonitorStateException
}
⚠️ 注意：getHoldCount() 是 ReentrantLock 的实例方法，必须在锁对象上调用，且仅在线程已获取锁的前提下才有意义（否则返回 0）。
替代思路：用 ThreadLocal 记录锁状态（不推荐）
有人尝试用 ThreadLocal<boolean></boolean> 手动标记，但这极易出错 —— 忘记清理、异常绕过 unlock、嵌套调用等都会导致状态不一致。ReentrantLock 自身的 getHoldCount() 已足够可靠，无需自行维护。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
