ReentrantReadWriteLock与同步
我们什么时候应该使用 的ReentrantReadWriteLock 相比， 同步 在Java的多线程环境中的关键字？
使用 ReentrantReadWriteLock而 不是Java中的 同步 有什么好处？
任何人都可以举一个例子（用Java）吗？
谢谢！
问题答案：
同步一次允许一个线程。
读/写锁可以同时允许多个读取器，但前提是没有写入器。因此，在某些使用情况下，由于读取器群体可以一起进行，因此我们可以获得更好的并发性。
Java API
文档提供了集合类的示例，这些类预期具有更多的读者而不是作家。
-
主要内容：1.ReentrantReadWriteLock 介绍,2.读写锁,3.读写锁源码分析1.ReentrantReadWriteLock 介绍 ReentrantReadWriteLock即可重入读写锁，其同时应用了共享锁和排斥锁，写锁使用排斥锁，读锁使用共享锁，从而实现读读共享，读写互斥，写写互斥。 当读操作远远高于写操作时,这时候使用读写锁让读——读可以并发,提高性能。 1.1 Sync 读写锁使用的是一个Sync同步器（使用一个对象），可以分别创建。有公平锁和非公平锁两种子类进
-
在我的实现类中，我有一个读写锁定义，如下所示， 我在一个名为的方法中使用它， 正如我所说的，是null，但是rwLock是初始化的。请解释Mockito是如何发生这种情况的。理想的方法是什么？
-
问题内容： 以下是典型的读写器模式（很多读取而很少写入） 我想知道是否有可能优先考虑作家和读者？例如，如果其他线程不断持有读取锁，通常writer可能会等待很长一段时间（也许永远），因此有可能使writer具有更高的优先级，因此只要有writer出现，就可以认为它是高优先级（跳过行）之类的。 问题答案： 按照javadoc的，JDK实现并 不会 有任何读/写器的优先级。但是，如果你使用了“公平”的
-
问题内容： Java专家 目前，我们有一个正被 频繁地读取和修改偶尔 ，我们有问题的修改过程中/重装， 读 操作返回这是不能接受的。 为了解决这个问题，我有以下选择： A.使用 ConcurrentHashMap 看起来像是首选，但是我们所讨论的操作是-表示紧随其后。因此，如果在读后读pre，则返回null，这是不希望的。即使我不能解决问题。 B.基于 ReentrantReadWriteLock
-
读者： 这看起来像是一个僵局，但有几件事让我怀疑： 我找不到另一个可能持有相同锁的线程 4秒后进行线程转储会得到相同的结果，但现在所有线程都报告，这与第一次转储中的不同。
-
谢谢你考虑我的问题，我认为这实际上是在问： 不太确定下面的代码会如何死锁。 其结构大致如下所示，有两个类: < li >具有同步方法的主类工作器 < li >具有类级别同步方法的util类 Worker的< code>run方法会死锁，使< code>doSomething()不同步可以避免死锁。 真实应用程序的线程转储显示： “Worker”线程被阻塞-正在等待监视器锁定-- 此处的“sched