关于读写锁的查询

Question

我正在研究java并发API并试图理解读写锁的有用性。 javadoc表示，一个readwrite块维护一对锁，一个用于读取，另一个用于写入操作。虽然写锁定是由线程独占访问的，但多个线程可以获取读锁定。因此，如果在读取部分中，我们所做的只是读取操作，而且我们无论如何都提供了多线程访问，那么首先需要使用readlock？有没有一种情况，当读写锁实际上有用？

Answer 1

....什么是需要有readlock摆在首位

阅读时，你需要防止作家获取锁......直到所有的读者都结束了。但另一个阅读器可以获取锁定。

在写作时，您需要防止读者获取锁定......直到作者完成。

（换句话说，也可以是一个作家，或者多个读者持有锁......但不能同时使用。）

为了描述本的目的，它是有帮助的的行为描述为两把锁。什么实际上发生在引擎盖......是具体实现。

---

是否有一个场景，当读写锁实际上是有用的？

好吧。在任何可以区分需要共享只读访问的线程和需要独占读写（或只写）的线程的情况下，ReadWrite锁允许比简单的Lock或原语互斥更多的并发。

Answer 2

如果您正在阅读许多主题中的数据，您可能不会看到由于可见性问题而导致的对数据的最新更改。有很多层可以在每个线程的基础上缓存数据：不同层的CPU缓存，RAM访问缓冲区等等。在你可能确定的地方，你可以阅读锁定，你总是在观察最新的状态。

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

这里有不同类型的锁的主要原因是有能力获得足够的同步水平，而不会为其他线程引入太多开销和锁。

有没有一种情况，当时读写锁实际上有用？

当你有一些内存中的数据（数组，集合或其他）时，它会非常有用，而这些数据会被不同的线程查询，但这种数据的更新很少发生。在这种情况下，具有单独的锁定（对查询进行读取锁定和对更新进行写入锁定）可能会给您带来显着的性能优势。

Answer 3

的原因有只读锁是，如果一些其它线程锁定写作的对象，该对象的状态可能是不一致的，所以你不想开始为无锁阅读它。获取读锁保证（1）对象是一致的状态，而你看着它，因为没有其他线程正在修改它，（2），其它线程不能开始修改它，直到你通过看它。我们将读锁定作为单独的类型，因为如果通常有很多线程可以读取，但只有少量更新，那么读者可以同时查看。