17370845950

答案：Java中Lock接口（如ReentrantLock）相比synchronized提供更灵活的显式锁控制，支持非阻塞获取、限时等待、可中断及多条件变量，适用于复杂并发场景。

在Java多线程编程中，当我们需要对共享资源进行访问控制，避免数据不一致时，同步机制是不可或缺的。

Lock

ReentrantLock

synchronized

解决方案

在Java中使用

Lock

synchronized

ReentrantLock

Lock

基本的使用模式如下：

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class SharedResource {
    private int count = 0;
    private final Lock lock = new ReentrantLock(); // 实例化一个可重入锁

    public void increment() {
        lock.lock(); // 显式获取锁
        try {
            // 这是受保护的临界区
            // 只有获取到锁的线程才能执行这里的代码
            count++;
            System.out.println(Thread.currentThread().getName() + " incremented count to: " + count);
        } finally {
            lock.unlock(); // 显式释放锁，这至关重要，必须放在finally块中
        }
    }

    public int getCount() {
        // 对于只读操作，如果其本身是原子性的，或者不涉及写操作，
        // 且对数据一致性要求不是绝对实时，可以考虑不加锁。
        // 但如果需要确保读取到最新、最一致的数据，或者读取过程复杂，
        // 仍然建议加锁，或者使用ReadWriteLock。
        lock.lock();
        try {
            return count;
        } finally {
            lock.unlock();
        }
    }

    public static void main(String[] args) {
        SharedResource resource = new SharedResource();

        Runnable task = () -> {
            for (int i = 0; i < 1000; i++) {
                resource.increment();
            }
        };

        Thread t1 = new Thread(task, "Thread-1");
        Thread t2 = new Thread(task, "Thread-2");

        t1.start();
        t2.start();

        try {
            t1.join();
            t2.join();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }

        System.out.println("Final count: " + resource.getCount());
    }
}

在这个例子中，

lock.lock()

lock.unlock()

unlock()

finally

Lock

• tryLock()

  ：尝试获取锁，如果锁当前不可用，则立即返回

  false

  ，不会阻塞。这对于避免死锁或实现更灵活的并发策略非常有用。

• tryLock(long timeout, TimeUnit unit)

  ：在指定时间内尝试获取锁，如果超时仍未获取到，则返回

  false

  。

• lockInterruptibly()

  ：获取锁，但如果当前线程在等待锁的过程中被中断，则会抛出

  InterruptedException

  。这为响应中断提供了可能。

• newCondition()

  ：返回一个

  Condition

  实例，可以实现更复杂的等待/通知机制，类似于

  Object

  的

  wait()

  、

  notify()

  和

  notifyAll()

  。一个

  Lock

  对象可以关联多个

  Condition

  对象，这在某些场景下提供了极大的灵活性。

为什么在有了

synchronized

关键字后，我们还需要

Lock

接口？

这确实是一个常被问到的问题。毕竟，

synchronized

synchronized

synchronized

synchronized

1. 无法尝试获取锁（非阻塞式获取）：

   synchronized

   只能阻塞式地获取锁。如果锁被其他线程持有，当前线程就只能傻等，直到锁被释放。但在某些场景下，我们可能希望“如果能拿到锁就做，拿不到就先干点别的”，比如避免死锁或提高用户界面的响应速度。
2. 无法限时获取锁：

   synchronized

   不支持在指定时间内尝试获取锁。
3. 无法中断正在等待锁的线程：一个线程一旦进入

   synchronized

   块的等待状态，就无法被中断，它会一直等到锁被释放。这在需要快速响应中断的长时间操作中是个问题。
4. 单一的等待/通知机制：

   synchronized

   依赖于

   Object

   的

   wait()

   、

   notify()

   和

   notifyAll()

   方法，这些方法是与每个对象唯一的监视器锁绑定的。这意味着一个对象只有一个“等待队列”，所有等待该对象锁的线程都在同一个队列里。如果需要区分不同条件下的等待线程，

   synchronized

   就显得力不从心了。
5. 不提供公平性选择：

   synchronized

   锁的获取是“不公平”的，即等待时间最长的线程不一定优先获得锁。这可能导致某些线程“饿死”（starvation）。

而

Lock

ReentrantLock

• 显式锁管理：通过

  lock()

  和

  unlock()

  方法，开发者可以精确控制锁的获取和释放时机。
• 非阻塞和限时锁获取：

  tryLock()

  和

  tryLock(long timeout, TimeUnit unit)

  方法允许线程尝试获取锁，而不会无限期阻塞，或者只在特定时间内等待。
• 可中断的锁获取：

  lockInterruptibly()

  方法允许在线程等待锁的过程中响应中断。
• 多条件变量：通过

  Lock

  的

  newCondition()

  方法，可以创建多个

  Condition

  对象，每个

  Condition

  都拥有自己独立的等待队列，从而实现更精细的等待/通知机制。这在生产者-消费者模型中，如果需要区分“缓冲区满”和“缓冲区空”两种等待状态时，非常有用。
• 公平性选择：

  ReentrantLock

  的构造函数允许你指定锁是否是“公平”的（

  new ReentrantLock(true)

  ），公平锁会优先将锁授予等待时间最长的线程，尽管这通常会带来一些性能开销。

所以，当我们面对需要更精细控制、避免死锁、提高响应性或实现复杂线程协作模式的场景时，

Lock

synchronized

使用

ReentrantLock

时有哪些常见的陷阱和最佳实践？

ReentrantLock

常见的陷阱：

1. 忘记释放锁：这是最常见也是最致命的错误。如果调用了

   lock()

   但没有在

   finally

   块中调用

   unlock()

   ，那么一旦临界区代码抛出异常，锁将永远不会被释放。这将导致其他所有尝试获取该锁的线程永久阻塞，造成死锁或程序“假死”。
   • 示例陷阱：

     lock.lock();
     // 临界区代码
     if (someCondition) {
         throw new RuntimeException("Oops!"); // 异常抛出，unlock()未执行
     }
     lock.unlock(); // 永远不会执行

2. 在不持有锁的情况下调用

   unlock()

   ：虽然

   ReentrantLock

   会抛出

   IllegalMonitorStateException

   ，但这种情况通常意味着逻辑错误。锁的释放必须由持有该锁的线程来完成。
3. 滥用公平锁：

   new ReentrantLock(true)

   创建的是公平锁，它会保证等待时间最长的线程优先获得锁，以避免饥饿。然而，公平锁通常比非公平锁的性能要差，因为它需要维护一个等待队列，并进行额外的上下文切换。在大多数情况下，如果不是有严格的公平性要求，非公平锁（默认）是更好的选择。
4. 不正确地使用

   Condition

   ：

   Condition

   是与

   Lock

   配合使用的等待/通知机制。如果不在持有锁的情况下调用

   Condition

   的

   await()

   、

   signal()

   或`

   signalAll()

   方法，会抛出

   IllegalMonitorStateException

   。
5. 临界区过大：将过多的代码放入锁的保护范围，会降低并发度，因为在任何时刻只有一个线程能执行这些代码。这会抵消多线程带来的性能优势。

最佳实践：

1. 始终在

   finally

   块中释放锁：这是最重要的原则。确保

   lock.unlock()

   被放置在

   try-finally

   结构中的

   finally

   块里，以保证锁总能被释放。

   lock.lock();
   try {
       // 临界区代码
   } finally {
       lock.unlock(); // 关键！
   }

2. 使用

   tryLock()

   避免死锁和提高响应性：当一个线程需要同时获取多个锁时，使用

   tryLock()

   （或带超时参数的

   tryLock()

   ）可以避免死锁。如果无法一次性获取所有锁，就释放已获取的锁，然后等待一段时间再重试。这比简单的阻塞等待更健壮。
3. 选择合适的锁公平性：默认的非公平锁通常性能更好。只有当你的应用确实有严格的线程饥饿问题或需要保证线程执行顺序时，才考虑使用公平锁。
4. 合理利用

   Condition

   ：当需要实现复杂的线程协作，比如生产者-消费者模型中，根据不同条件（缓冲区满/空）唤醒特定线程组时，

   Condition

   是

   Object.wait/notify

   的强大替代品。记住，

   await()

   、

   signal()

   等方法必须在持有锁的情况下调用。
5. 保持临界区尽可能小：只将真正需要同步的代码放入

   lock()

   和

   unlock()

   之间。减少锁的持有时间可以显著提高并发性能。
6. 考虑使用

   lockInterruptibly()

   ：对于可能长时间等待锁的线程，如果允许它们在等待过程中被中断，那么使用

   lockInterruptibly()

   是一个好选择。这样可以使程序更具响应性，例如在用户取消操作时。
7. 理解可重入性：

   ReentrantLock

   是可重入的，这意味着持有锁的线程可以再次获取该锁而不会死锁。这对于递归调用或内部方法也需要获取相同锁的情况非常有用。但也要注意，每次

   lock()

   都必须对应一次

   unlock()

   ，否则锁无法完全释放。

遵循这些最佳实践，可以帮助我们更安全、高效地使用

ReentrantLock

Lock

接口与

synchronized

关键字在性能上有什么差异？

关于

Lock

ReentrantLock

synchronized

历史背景与早期认知： 在Java早期版本中，

synchronized

ReentrantLock

现代JVM的优化： 然而，现代JVM（尤其是HotSpot JVM）对

synchronized

• 偏向锁（Biased Locking）：当锁只被一个线程反复获取和释放时，JVM会“偏向”这个线程，减少锁操作的开销。
• 轻量级锁（Lightweight Locking）：当多个线程交替获取锁，但没有发生激烈竞争时，JVM会使用CAS操作而非操作系统互斥量，减少上下文切换。
• 自旋锁（Spin Locking）：当一个线程尝试获取锁但锁被短暂持有，它不会立即阻塞，而是会“自旋”一段时间，尝试再次获取锁，避免线程上下文切换的开销。
• 锁消除（Lock Elision）和锁粗化（Lock Coarsening）：JIT编译器在某些情况下能够完全消除不必要的锁操作，或者将多个连续的锁操作合并为一个，进一步提高性能。

当前的性能对比：

1. 简单竞争场景（低竞争或无竞争）： 在大多数低竞争或无竞争的场景下，

   synchronized

   关键字的性能可能与

   ReentrantLock

   相当，甚至在某些情况下略优。现代JVM的优化使得

   synchronized

   的开销非常小，尤其是在偏向锁和轻量级锁生效时。

   ReentrantLock

   虽然底层也使用CAS，但其API调用本身（如方法调用、对象创建）会带来一定的额外开销。
2. 高竞争场景： 在高竞争场景下，

   ReentrantLock

   可能会展现出更好的性能优势。这主要得益于它提供了更灵活的控制，例如

   tryLock()

   和

   lockInterruptibly()

   ，这些功能可以帮助开发者编写更智能的并发代码，减少不必要的阻塞和上下文切换，从而在整体上提高系统的吞吐量和响应性。此外，

   ReentrantLock

   可以选择公平性，虽然公平锁本身有性能开销，但在避免线程饥饿、优化特定业务逻辑时，这种控制能力可能间接带来更好的整体性能。
3. 功能性差异带来的间接性能影响：

   ReentrantLock

   提供的

   Condition

   机制允许更细粒度的等待/通知，可以避免

   synchronized

   的

   wait/notifyAll

   可能造成的“惊群效应”（thundering herd），即唤醒了所有等待线程，但其中大部分线程发现条件仍不满足又重新进入等待状态，这会造成不必要的上下文切换和资源消耗。在复杂场景下，

   Condition

   的精准唤醒能力可以显著提升性能。

总结与选择建议：

• 简单同步需求：如果只是简单的互斥访问，且对锁的控制没有特殊要求（如非阻塞、限时、可中断），优先考虑使用

  synchronized

  关键字。它代码简洁、易于理解，并且现代JVM对其优化得非常好，性能通常足够满足需求。
• 复杂同步需求：当需要更高级的锁功能时，例如：
  • 尝试获取锁而不阻塞 (

    tryLock()

    )
  • 限时获取锁 (

    tryLock(timeout, unit)

    )
  • 可中断地获取锁 (

    lockInterruptibly()

    )
  • 需要多个条件变量 (

    Condition

    ) 实现复杂的等待/通知机制
  • 需要选择锁的公平性
  • 需要实现读写分离锁 (

    ReentrantReadWriteLock

    ) 此时，

    Lock

    接口及其实现（如

    ReentrantLock

    ）是更好的选择。虽然可能带来轻微的直接性能开销，但其提供的灵活性和控制力，能够帮助你编写出更高效、更健壮的并发代码，从而在整体系统层面实现更好的性能。

最终，对于性能敏感的应用，最好的方法始终是进行实际的基准测试。在你的具体应用场景下，通过测试数据来决定哪种同步机制最适合。但总的来说，不要盲目认为

Lock

synchronized