Java可重入锁原理与机制解析

今天golang学习网给大家带来了《Java可重入锁详解：锁的重入机制解析》，其中涉及到的知识点包括等等，无论你是小白还是老手，都适合看一看哦~有好的建议也欢迎大家在评论留言，若是看完有所收获，也希望大家能多多点赞支持呀！一起加油学习~

可重入锁允许同一线程多次获取同一把锁而不阻塞，其核心是“线程绑定+计数器”机制，通过state值记录加锁次数、持有线程引用确保仅该线程可重入；用于避免嵌套调用死锁，支持公平/非公平模式，且必须配合try-finally确保unlock。

可重入锁（ReentrantLock）是指同一个线程可以多次获取同一把锁，而不会因重复加锁导致自己被阻塞。这是它最核心的特性，也是区别于某些原始锁机制的关键所在。

可重入锁的本质是“线程绑定 + 计数器”

每个 ReentrantLock 内部维护两个关键信息：

• 一个 state 状态值：表示当前锁被同一线程获取的次数；初始为 0，每成功加锁一次就 +1，释放一次就 -1，直到归零才算真正释放
• 一个 持有锁的线程引用：记录当前哪个线程正占有该锁；只有这个线程才能反复加锁或解锁

当线程再次调用 lock() 时，锁会检查当前线程是否就是持有者——如果是，直接增加 state 并返回，不排队也不阻塞。

为什么需要可重入？解决嵌套调用死锁

在实际开发中，一个方法加了锁，内部又调用了另一个也需加锁的私有方法，如果锁不可重入，就会造成自己等自己，发生死锁。

• 比如：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，避免重复释放或遗漏

好了，本文到此结束，带大家了解了《Java可重入锁原理与机制解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！