可重入锁是什么？synchronized为何可重入

大家好，今天本人给大家带来文章《可重入锁是什么？synchronized为何是可重入的》，文中内容主要涉及到，如果你对文章方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！

可重入锁允许持有锁的线程重复获取同一把锁而不发生阻塞，synchronized和ReentrantLock均实现该特性。JVM通过监视器的持有者线程ID和计数器实现synchronized的可重入，线程首次获取锁时计数器为1，重入时递增，退出同步块时递减，归零后释放锁。ReentrantLock基于AQS框架，通过state变量和持有线程引用实现，支持公平锁、可中断获取、tryLock等高级功能。两者均避免自死锁，适用于递归调用、模块化设计等场景，synchronized更简洁安全，ReentrantLock在高竞争或需细粒度控制时更具优势。

可重入锁允许持有锁的线程在不释放锁的情况下，再次获取该锁。synchronized关键字实现的锁就是一种典型的可重入锁，这意味着当一个线程已经获得了某个对象的锁，它就可以继续进入该对象其他或相同的同步代码块，而不会发生死锁。JVM内部会追踪线程获取锁的次数。

解决方案

可重入锁的核心在于，它识别当前尝试获取锁的线程是否就是已经持有该锁的线程。如果是同一个线程，它就可以“重新进入”临界区，而不会被阻塞。这种机制避免了线程因为自己持有锁而无法再次获取锁，从而导致死锁的尴尬局面。

具体来说，当一个线程首次获取可重入锁时，锁的计数器会加一。如果同一个线程再次尝试获取该锁，计数器会再次加一，并且锁仍然由该线程持有。只有当计数器归零时，锁才会被完全释放，其他等待的线程才有机会获取它。

synchronized关键字在Java中就是通过这种机制工作的。当你使用synchronized(this)或synchronized方法时，JVM会为当前对象（或类）关联一个监视器（Monitor）。当一个线程进入同步块时，它会尝试获取这个监视器。如果该线程已经持有这个监视器，它就可以直接进入，监视器的内部计数器会递增。当线程退出同步块时，计数器会递减。只有当计数器减到零时，监视器才会被完全释放。

举个例子，假设你有一个方法methodA是同步的，它又调用了另一个同步方法methodB，而methodB又调用了methodC。如果这三个方法都同步在同一个对象上，那么持有锁的线程可以从methodA顺利进入methodB，再进入methodC，而不会因为尝试获取一个自己已经持有的锁而被阻塞。

public class ReentrantExample {
    public synchronized void outerMethod() {
        System.out.println(Thread.currentThread().getName() + " 进入 outerMethod");
        innerMethod();
        System.out.println(Thread.currentThread().getName() + " 退出 outerMethod");
    }

    public synchronized void innerMethod() {
        System.out.println(Thread.currentThread().getName() + " 进入 innerMethod");
        // 可以在这里调用更深层次的同步方法
        // deepInnerMethod();
        System.out.println(Thread.currentThread().getName() + " 退出 innerMethod");
    }

    public static void main(String[] args) {
        ReentrantExample example = new ReentrantExample();
        new Thread(() -> example.outerMethod(), "Thread-1").start();
    }
}

在这个例子中，Thread-1进入outerMethod时获取了example对象的锁，然后它又能顺利地进入innerMethod，因为innerMethod也是同步在同一个example对象上的。这就是synchronized可重入性的直接体现。

深入理解可重入锁的实现原理与内部机制

可重入锁的实现，无论是synchronized还是java.util.concurrent.locks.ReentrantLock，其核心都在于两个关键要素：锁的持有者（Owner）和获取计数（Acquisition Count）。

对于synchronized而言，这一切都由JVM底层自动完成。每个Java对象在内存中都关联着一个监视器（Monitor），这个监视器在概念上包含了锁的持有者线程ID和一个计数器。当一个线程尝试进入synchronized块时：

1. JVM会检查该监视器是否已经被持有。
2. 如果未被持有，当前线程成为持有者，计数器设为1。
3. 如果已被持有，JVM会进一步检查持有者是否就是当前线程。
4. 如果是当前线程，计数器加1，允许线程继续执行。
5. 如果不是当前线程，当前线程就会被阻塞，直到锁被释放。 当线程退出synchronized块时，计数器减1。只有当计数器减到0时，监视器才会被完全释放，其他等待的线程才可能获取到它。这个过程是透明的，我们开发者无需手动管理。

而对于ReentrantLock，它的实现则更为显式和灵活，它基于Java的抽象队列同步器（AbstractQueuedSynchronizer, AQS）框架。AQS内部维护了一个state变量来表示锁的获取状态（这就是我们的计数器），以及一个指向当前持有锁的线程的引用。

• 当一个线程调用lock()方法时：
  • 它会尝试原子性地将state从0变为1。如果成功，当前线程就成为锁的持有者。
  • 如果state不为0，它会检查当前持有锁的线程是否就是自己。
  • 如果是自己，就将state加1，实现重入。
  • 如果不是自己，线程就会被封装成一个节点，加入到AQS的等待队列中，并被park（挂起）。
• 当线程调用unlock()方法时：
  • state减1。
  • 如果state减到0，表示锁完全释放，当前线程将不再是持有者，并会唤醒等待队列中的下一个线程。

这种设计使得ReentrantLock不仅支持可重入，还能在此基础上提供公平性选择、尝试非阻塞获取锁（tryLock()）以及条件变量（Condition）等高级功能，这些是synchronized无法直接提供的。

可重入锁在多线程编程中的核心价值与应用场景

可重入锁的存在，极大地简化了多线程编程中对共享资源的访问控制，避免了许多潜在的死锁和逻辑复杂性。其核心价值在于它允许“信任”当前持有锁的线程，让其能够自由地调用其他需要相同锁的同步方法或代码块。

最直接的价值体现在避免自死锁（Self-Deadlock）。如果没有可重入性，一个线程在进入一个同步方法后，如果该方法内部又调用了另一个需要相同锁的同步方法，线程就会尝试再次获取一个它自己已经持有的锁，从而导致永久阻塞，形成一个经典的自死锁。可重入锁机制优雅地解决了这个问题，确保了线程在自身操作上的流畅性。

常见的应用场景包括：

1. 递归方法调用：如果一个递归方法本身是同步的，或者在递归过程中需要访问受保护的共享资源，可重入锁是不可或缺的。例如，一个计算阶乘的同步方法，在递归调用自身时，能够顺利地重入，而不会卡死。

   public class FactorialCalculator {
       private int result;
       public synchronized int calculate(int n) {
           if (n <= 1) {
               result = 1;
               return 1;
           }
           // 递归调用自身，再次获取锁，因为是可重入的，所以不会死锁
           int temp = n * calculate(n - 1);
           result = temp; // 假设需要同步更新结果
           return temp;
       }
   }

2. 封装与模块化设计：在面向对象设计中，一个类可能包含多个方法，它们都操作同一个内部状态，因此都需要对同一个对象进行同步。如果一个外部方法调用了内部方法，而内部方法也需要同步，可重入锁就保证了这种调用链的顺畅。它允许我们更自然地封装和组合同步逻辑，而无需担心因锁的重复获取而导致的阻塞。

3. 框架与库的实现：许多Java并发框架和库在内部实现时，都依赖于可重入锁来保证其内部状态的一致性，同时允许调用者以直观的方式使用这些API，而不用担心底层锁的复杂性。

总的来说，可重入锁使得同步机制更加健壮和易于使用，它允许线程在已经拥有资源访问权限的前提下，继续进行与其相关的操作，这符合我们对“拥有权限”的直观理解。

synchronized 与 ReentrantLock 在可重入特性上的异同与选择考量

synchronized和ReentrantLock都提供了可重入的锁机制，但它们在用法、功能和底层实现上有着显著的区别，这直接影响了我们在不同场景下的选择。

相同点：

• 可重入性：这是它们最基本的共同点。两者都允许持有锁的线程再次获取该锁，避免了自死锁。
• 保证原子性、可见性和有序性：作为锁，它们都能确保在多线程环境下对共享资源的访问是线程安全的。

不同点：

1. 实现方式与控制粒度：

   • synchronized：是Java语言的关键字，由JVM隐式管理。它的锁是基于对象的监视器（Monitor），自动加锁和释放锁。我们无法直接访问或控制锁的状态。
   • ReentrantLock：是java.util.concurrent.locks包下的一个类，它是一个显式锁。需要手动调用lock()方法获取锁，并在finally块中调用unlock()方法释放锁。这赋予了开发者更高的控制粒度。

2. 功能扩展性：

   • synchronized：功能相对单一，只支持最基本的互斥和可重入。无法实现尝试非阻塞获取锁、限时获取锁、公平锁、多个条件变量等高级功能。
   • ReentrantLock：提供了更丰富的功能。例如：
     • tryLock()：尝试获取锁，如果获取不到立即返回，避免阻塞。
     • tryLock(long timeout, TimeUnit unit)：在指定时间内尝试获取锁，超时则返回。
     • lockInterruptibly()：可响应中断的获取锁方式。
     • 公平性：可以构造公平锁（new ReentrantLock(true)），按请求顺序获取锁，但性能通常低于非公平锁。
     • 条件变量（Condition）：通过newCondition()方法可以创建多个条件变量，实现更精细的线程间协作（await()和signal()/signalAll()）。

3. 性能：

   • 在早期Java版本中，synchronized的性能通常低于ReentrantLock。但随着JVM的不断优化（如偏向锁、轻量级锁、自旋锁），synchronized的性能已经得到了极大提升，在许多场景下甚至与ReentrantLock不相上下，甚至更好。对于简单的同步需求，synchronized通常表现优秀。
   • ReentrantLock在竞争激烈或需要高级功能的场景下，其性能优势和灵活性会更加明显。

选择考量：

• 简洁性与习惯：如果同步需求简单，仅仅是保护一段代码或一个方法，synchronized无疑是更简洁、更直观的选择。它由JVM自动管理锁的释放，避免了忘记unlock()可能导致的死锁问题。这也是Java开发者最常用的同步机制。
• 高级功能需求：当你需要更细粒度的控制，比如：
  • 尝试非阻塞地获取锁（避免长时间等待）。
  • 在特定条件下等待（使用多个Condition）。
  • 需要一个可中断的锁获取机制。
  • 对锁的公平性有明确要求。
  • 此时，ReentrantLock就是更好的选择。它的API设计使得这些高级并发模式的实现变得可能。
• 避免死锁风险：使用ReentrantLock时，务必记住在finally块中释放锁，否则一旦同步块内发生异常，锁将永远不会被释放，导致严重的死锁。synchronized则没有这个风险，因为JVM会保证锁的正确释放。
• 代码可读性与维护：对于简单的同步，synchronized的代码更紧凑，可读性高。ReentrantLock的代码会稍微冗长一些，但如果其带来的高级功能是必要的，那么这种额外的复杂性是值得的。

总而言之，对于大多数简单的互斥场景，synchronized是首选，因为它简单、安全且性能优异。只有当synchronized无法满足特定需求时，才考虑使用ReentrantLock。这是一个权衡简洁性、安全性和功能灵活性的选择。

到这里，我们也就讲完了《可重入锁是什么？synchronized为何可重入》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于JVM,synchronized,reentrantlock,可重入锁,AQS的知识点！