使用 ReentrantLock 替代 synchronized 实现更灵活的锁控制

在 Java 多线程编程中，synchronized 是最常用的同步机制之一，但它的使用存在一些局限性，比如无法灵活地控制锁的获取和释放时机、无法实现公平锁、没有条件变量等。而 ReentrantLock 则提供了比 synchronized 更加灵活的锁机制控制。

ReentrantLock 是可重入的锁，可以被同一个线程多次获取，保证了线程在获取锁时的公平性。我们可以显式地调用 lock() 方法获取锁，以及 unlock() 方法释放锁，从而在更精细的粒度上控制锁的获取和释放。与之相比，synchronized 是隐式的，锁的获取和释放是由 JVM 自动管理的，无法像 ReentrantLock 那样灵活。

此外，ReentrantLock 提供了 tryLock() 方法，它尝试获取锁，如果获取不到则立即返回 false，而不会像 lock() 方法那样无限期地等待。这使得我们可以在尝试获取锁时进行一些额外的逻辑处理，比如记录日志、进行超时控制等。

我们还可以结合 Condition 对象使用 ReentrantLock，实现更加复杂的等待/通知机制。这类似于 synchronized 中的 wait()、notify() 和 notifyAll() 方法，但 Condition 提供了更灵活的控制，比如可以创建多个 Condition 对象，针对不同的条件进行等待和通知。

例如，在一个生产者 - 消费者模式中，我们可以使用 ReentrantLock 和 Condition 来实现生产者和消费者之间的同步。生产者在生产完产品后调用 Condition 的 signalAll() 方法通知所有消费者，而消费者在消费完产品后调用 signalAll() 方法通知所有生产者。这种方式比使用 synchronized 的 wait() 和 notifyAll() 方法更加清晰和灵活。

在实际使用中，需要注意避免死锁问题。确保在获取锁和释放锁的代码块中不会出现死循环或者长时间阻塞的情况，同时在 finally 块中释放锁是至关重要的，以保证锁能够被正确释放。