有关读写锁的查询

Question

我正在研究java并发API，并试图了解读写锁的有用性。javadoc表示ReadW区块维护一对锁，一个用于读，另一个用于写操作。当写锁是由线程独占访问时，多个线程可以获得读锁。因此，如果在read部分中，我们所做的只是读取操作，并且无论如何都提供多个线程访问，那么首先需要重新锁定什么呢？是否存在readwrite锁实际有用的场景？

Answer 1

……首先有什么需要重新锁定？

当你阅读的时候，你需要阻止一个作家获得锁.直到所有的读者都完成。但是对于另一个读者来说，获得锁是可以的。

在写作的时候，你需要阻止读者获得锁.直到作家写完为止。

(换句话说，可以有一个作者，或多个读者持有锁.但不是两者兼而有之。

为了描述这一点，将行为描述为两个锁是很有帮助的。引擎盖下面到底发生了什么..。是具体的实现。

是否存在readwrite锁实际有用的场景？

是啊是啊。在任何情况下，您可以区分需要共享只读访问的线程和需要独占读写(或只写)的线程，ReadWrite锁比简单的Lock或原始互斥锁允许更多的并发性。

Answer 2

如果在许多线程中读取数据，则由于可见性问题，很可能不会看到对数据的最新更改。有许多层可以在每个线程的基础上缓存数据: CPU缓存的不同层、RAM访问缓冲区等等。你可以肯定的是，你总是在观察最新的状态。

写锁甚至更强大，提供了访问的原子性以及最新更改的可见性。

在这里拥有不同类型的锁的主要原因是能够在不给其他线程引入太多开销和锁的情况下获得足够的同步级别。

是否存在readwrite锁实际有用的场景？

当您有一些内存中的数据(Array、Collection或其他什么)时，它非常有用，这些数据被不同的线程大量查询，但是这些数据的更新很少发生。在这种情况下，拥有单独的锁(查询的读锁和更新的写锁)可能会给您带来很大的性能好处。

Answer 3

拥有只读锁的原因是，如果其他线程有一个用于写入的对象，则该对象的状态可能不一致，因此您根本不希望在没有锁的情况下开始读取它。获取读锁可以确保(1)在查看对象时对象处于一致状态，因为没有其他线程正在修改它；(2)在查看完对象之前，没有其他线程可以开始修改它。我们将读锁作为一个单独的类型，因为如果很多线程通常都要读取，但是很少更新，那么读取器都可以同时阅读。