可重入锁允许同一线程多次获取同一把锁而不阻塞，其核心是“线程绑定+计数器”机制，通过state值记录加锁次数、持有线程引用确保仅该线程可重入；用于避免嵌套调用死锁，支持公平/非公平模式，且必须配合try-finally确保unlock。
可重入锁（ReentrantLock）是指同一个线程可以多次获取同一把锁，而不会因重复加锁导致自己被阻塞。这是它最核心的特性，也是区别于某些原始锁机制的关键所在。
可重入锁的本质是“线程绑定 + 计数器”
每个 ReentrantLock 内部维护两个关键信息：
- 一个 state 状态值：表示当前锁被同一线程获取的次数；初始为 0，每成功加锁一次就 +1，释放一次就 -1，直到归零才算真正释放
- 一个 持有锁的线程引用：记录当前哪个线程正占有该锁；只有这个线程才能反复加锁或解锁
当线程再次调用 lock() 时，锁会检查当前线程是否就是持有者——如果是，直接增加 state 并返回，不排队也不阻塞。
为什么需要可重入？解决嵌套调用死锁
在实际开发中，一个方法加了锁，内部又调用了另一个也需加锁的私有方法，如果锁不可重入，就会造成自己等自己，发生死锁。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 比如：
public void doWork() { lock.lock(); try { process(); } finally { lock.unlock(); } } - 而
process()内部又写了lock.lock()—— 可重入锁允许这种写法安全执行 - 这和
synchronized的行为一致，但 ReentrantLock 提供了更细粒度的控制能力
公平性与非公平性影响获取顺序
ReentrantLock 支持两种构造方式：
- 非公平模式（默认）：新线程可能插队，直接尝试抢锁，吞吐量高，但可能让等待久的线程“饿死”
-
公平模式（new ReentrantLock(true)）：严格按调用
lock()的先后顺序排队，避免饥饿，但性能略低
注意：公平性只影响“未持有锁时的竞争”，不影响可重入逻辑本身。
使用时必须配对释放，推荐 try-finally 结构
由于 ReentrantLock 是显式锁，不会像 synchronized 那样自动释放，漏掉 unlock() 就会导致其他线程永久阻塞。
- 务必在
finally块中调用unlock() - 即使加锁后抛出异常，也能确保释放
- 不要在不同分支里分别 unlock，避免重复释放或遗漏
