ReentrantReadWriteLock读写锁使用详解

ReentrantReadWriteLock通过读写锁分离实现读多写少场景下的高效并发控制，允许多个读线程同时访问，写线程独占访问，提升性能。

Java中的ReentrantReadWriteLock，在我看来，它就是并发世界里的一把“分时复用”钥匙，巧妙地平衡了数据的读取效率和写入安全。它的核心思想很简单：当数据只需要被读取时，允许多个线程同时进行，大家互不影响，效率自然就上去了；但一旦有线程想要修改数据，它就必须独占这把钥匙，确保修改过程不被任何读取或写入操作干扰，保证数据的一致性。这种机制特别适合那些“读多写少”的场景，比如一个缓存系统，或者一个配置中心，大部分时间都在被查询，偶尔才更新一次。

当我们需要在Java中实现一个高效且线程安全的数据访问机制，特别是面对读操作远多于写操作的场景时，ReentrantReadWriteLock提供了一个非常优雅的解决方案。它通过区分读锁（ReadLock）和写锁（WriteLock）来优化并发性能。

解决方案

要使用ReentrantReadWriteLock，我们首先需要创建一个实例，然后通过它的readLock()和writeLock()方法获取对应的锁。

import java.util.concurrent.locks.ReentrantReadWriteLock;

public class SharedResource {
    private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
    private final ReentrantReadWriteLock.ReadLock readLock = rwLock.readLock();
    private final ReentrantReadWriteLock.WriteLock writeLock = rwLock.writeLock();

    private String data = "Initial Data";

    public String readData() {
        readLock.lock(); // 获取读锁
        try {
            // 模拟读取操作
            System.out.println(Thread.currentThread().getName() + " is reading: " + data);
            Thread.sleep(50); // 模拟耗时
            return data;
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return null;
        } finally {
            readLock.unlock(); // 释放读锁
        }
    }

    public void writeData(String newData) {
        writeLock.lock(); // 获取写锁
        try {
            // 模拟写入操作
            System.out.println(Thread.currentThread().getName() + " is writing: " + newData);
            Thread.sleep(100); // 模拟耗时
            this.data = newData;
            System.out.println(Thread.currentThread().getName() + " finished writing.");
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            writeLock.unlock(); // 释放写锁
        }
    }

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

        // 多个读线程
        for (int i = 0; i < 5; i++) {
            new Thread(() -> {
                resource.readData();
            }, "Reader-" + i).start();
        }

        // 一个写线程
        new Thread(() -> {
            resource.writeData("New Data from Writer-1");
        }, "Writer-1").start();

        // 另一个写线程
        new Thread(() -> {
            resource.writeData("New Data from Writer-2");
        }, "Writer-2").start();

        // 更多的读线程
        for (int i = 5; i < 10; i++) {
            new Thread(() -> {
                resource.readData();
            }, "Reader-" + i).start();
        }
    }
}

在这个例子中，readData()方法通过获取读锁来保护数据读取，允许多个线程同时进入。而writeData()方法则通过获取写锁来保护数据写入，任何时候只有一个线程能持有写锁，并且在写锁被持有时，所有读锁和写锁都无法被其他线程获取，确保了数据修改的原子性和可见性。

ReentrantReadWriteLock相比ReentrantLock有哪些优势和应用场景？

ReentrantReadWriteLock最显著的优势，就是它打破了ReentrantLock那种“一夫当关，万夫莫开”的独占模式。ReentrantLock在任何时候都只允许一个线程访问临界区，无论是读还是写，这在读操作频繁的场景下会造成严重的性能瓶颈。比如，一个电商网站的商品详情页，用户点击量巨大，都是在读取商品信息；而商品信息的更新（价格调整、库存变化）相对较少。如果用ReentrantLock，每次有用户读取商品信息，其他所有想读的、想写的都得排队，这显然不合理。

ReentrantReadWriteLock的出现，正是为了解决这种“读多写少”的痛点。它允许：

1. 多读并发： 多个线程可以同时持有读锁，并行读取数据，大大提升了读取效率。
2. 写独占： 任何时候只有一个线程能持有写锁，且在写锁被持有时，读锁和写锁都不能被其他线程获取，保证了数据写入的一致性和安全性。

因此，它的应用场景非常明确：

• 缓存系统： 这是最典型的场景。缓存数据被频繁读取，偶尔才会被更新或失效。读写锁可以确保缓存的高效访问。
• 配置管理： 应用程序的配置信息，一旦加载后，通常是读多写少。
• 数据结构封装： 对一些非线程安全的数据结构（如ArrayList、HashMap）进行线程安全封装，使其在读多写少的场景下表现更优。
• 监控数据： 收集到的监控指标，需要被多个组件读取，但更新频率不高。

简单来说，当你的程序中存在一个共享资源，其读操作的频率远高于写操作时，ReentrantReadWriteLock就是你提升并发性能的利器。如果读写比例接近，或者写操作非常频繁，那么ReentrantLock或者其他更细粒度的同步机制可能更适合，因为ReentrantReadWriteLock内部的维护开销会相对大一些。

ReentrantReadWriteLock的写锁和读锁有哪些核心特性和使用陷阱？

ReentrantReadWriteLock的设计非常精妙，但要用好它，我们必须理解其读锁和写锁的核心特性以及一些潜在的使用陷阱。

写锁 (WriteLock) 的核心特性：

1. 独占性： 这是最基本的，任何时候只能有一个线程持有写锁。当一个线程持有写锁时，其他所有试图获取读锁或写锁的线程都会被阻塞。
2. 重入性： 持有写锁的线程可以再次获取写锁。这在递归调用或者同一线程内部需要多次加锁的场景下非常有用，避免了死锁。
3. 允许降级： 持有写锁的线程可以获取读锁，然后释放写锁。这个过程称为“锁降级”。它常用于在修改完数据后，需要继续读取修改后的数据，同时允许其他线程读取（但不能写入）的场景。例如：

   writeLock.lock();
   try {
       // 修改数据
       data = "Modified Data";
       readLock.lock(); // 获取读锁
   } finally {
       writeLock.unlock(); // 释放写锁
   }
   // 现在持有读锁，可以安全读取，其他线程也可以读取
   String currentData = data;
   readLock.unlock();

读锁 (ReadLock) 的核心特性：

1. 共享性： 多个线程可以同时持有读锁。这是它与写锁最大的区别，也是实现高并发读取的关键。
2. 重入性： 持有读锁的线程可以再次获取读锁。
3. 阻止写操作： 当有任何线程持有读锁时，其他线程无法获取写锁。这意味着读锁可以阻止数据在读取过程中被修改。
4. 不允许升级： 读锁不能直接升级为写锁。也就是说，一个线程在持有读锁的情况下，不能直接尝试获取写锁。如果这样做，很可能会导致死锁。

使用陷阱和注意事项：

1. 读锁升级为写锁的死锁风险： 这是最常见的陷阱。如果线程A持有读锁，尝试获取写锁；同时线程B也持有读锁，也尝试获取写锁。那么两个线程都会因为对方持有读锁而无法获取写锁，导致相互等待，形成死锁。正确的做法是先释放读锁，再尝试获取写锁，但这会引入一个短暂的窗口期，期间数据可能被其他线程修改。所以，通常不建议在持有读锁时直接尝试获取写锁。
2. 写饥饿： 在高并发的读操作场景下，如果读锁被持续不断地获取和释放，写锁可能会因为无法获取而长时间等待，导致写线程“饥饿”。ReentrantReadWriteLock的默认实现（非公平模式）在一定程度上会缓解这个问题，但公平模式下，如果写锁在等待，后续的读锁请求会被阻塞，直到写锁被释放，这又可能影响读的并发性。这是一个权衡问题，需要根据实际业务场景选择。
3. 锁粒度： 像所有锁一样，ReentrantReadWriteLock也需要注意锁的粒度。如果锁定的范围过大，会降低并发性；如果过小，又可能导致数据不一致或者增加锁管理的复杂性。
4. 异常处理： 务必在finally块中释放锁，避免因异常导致锁无法释放，进而造成死锁或资源泄露。这是使用任何Lock接口的黄金法则。

理解这些特性和陷阱，能够帮助我们更安全、高效地利用ReentrantReadWriteLock来构建健壮的并发程序。

如何选择ReentrantReadWriteLock的公平性策略，以及公平性对性能的影响？

ReentrantReadWriteLock和ReentrantLock一样，都支持公平（Fair）和非公平（Nonfair）两种锁获取策略。在创建ReentrantReadWriteLock实例时，可以通过构造函数指定：new ReentrantReadWriteLock(boolean fair)。

公平性策略的选择：

1. 公平锁 (Fair Lock)：

   • 工作方式： 当一个线程尝试获取锁时，如果当前锁被占用，它会进入一个等待队列。当锁被释放时，等待队列中最前面的线程（等待时间最长的线程）会优先获取锁。这保证了线程获取锁的顺序与它们请求锁的顺序一致。
   • 优点： 避免饥饿。所有等待的线程都有机会获取锁，不会出现某个线程一直无法获取锁的情况。
   • 缺点： 性能开销较大。因为需要维护一个有序的等待队列，并且在释放锁时进行额外的线程调度，上下文切换的成本更高。这通常会导致吞吐量下降。
   • 适用场景： 对线程公平性有严格要求，或者需要避免写饥饿的特定场景，尽管在ReentrantReadWriteLock中，公平模式下写锁饥饿问题可能会被缓解，但读锁的并发性会受影响。

2. 非公平锁 (Nonfair Lock)：

   • 工作方式： 当一个线程尝试获取锁时，它会先尝试直接获取锁。如果锁当前可用，它就立即获取，而不管等待队列中是否有其他线程。只有当锁不可用时，它才会进入等待队列。
   • 优点： 性能通常优于公平锁。减少了线程调度的开销，提高了吞吐量。
   • 缺点： 可能会导致饥饿。新来的线程可能会“插队”成功，导致等待队列中的线程长时间无法获取锁。
   • 适用场景： 大多数并发编程场景。在没有严格公平性要求，且追求高吞吐量时，非公平锁是更好的选择。这也是ReentrantReadWriteLock和ReentrantLock的默认行为。

公平性对性能的影响：

公平性策略对ReentrantReadWriteLock的性能影响是显著的。

• 非公平锁通常提供更高的吞吐量： 这是因为非公平锁减少了线程上下文切换的开销。当锁被释放时，如果当前有线程正在尝试获取锁（而不是等待队列中的线程），它可能直接成功，避免了将等待队列中的线程唤醒、调度、上下文切换等一系列操作。这种“抢占”机制在CPU利用率高时尤其明显。
• 公平锁在某些情况下可能导致性能下降： 尤其是在高并发场景下，频繁的线程入队、出队以及严格的顺序保证会引入额外的开销。对于读写锁来说，公平性还会影响读写之间的调度。在公平模式下，如果一个写锁在等待，那么所有后续的读锁请求也会被阻塞，直到写锁被释放，这会牺牲读操作的并发性来确保写操作的公平性。而在非公平模式下，如果写锁正在等待，但此时没有线程持有读锁，并且有新的读锁请求到来，这个读锁请求可能会“插队”成功，继续进行读操作。

我的建议：

除非你有明确的业务需求，要求严格的线程公平性或者需要解决特定的饥饿问题，否则我通常会推荐使用非公平锁。默认的非公平模式在大多数情况下都能提供更好的性能和吞吐量。在实际开发中，我们应该根据应用的具体负载特性和性能目标来选择合适的公平性策略，并且在做出决策后进行充分的性能测试。毕竟，理论上的最优解不一定适用于所有实际场景。