java ReentrantReadWriteLock 与同步
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6637170/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
ReentrantReadWriteLock vs synchronized
提问by Mike
When should we use ReentrantReadWriteLockas compared to synchronizedkeyword in multithreaded environment in Java?
与Java 多线程环境中的synchronized关键字相比，我们什么时候应该使用ReentrantReadWriteLock？
What are the benefits of using ReentrantReadWriteLockover synchronizedin Java?
在 Java中使用ReentrantReadWriteLock比使用同步有什么好处？
Can any one give an example as well (in Java)?
任何人也可以举一个例子（在Java中）吗？
Thanks!
谢谢！
回答by djna
Synchronized allows in one thread at a time.
同步允许一次一个线程。
Read/Write locks allow in multiple readers a the same time, but only if no writers are already in. Hence under some usage scenarios we can get better concurrency, because the reader populations can proceed together.
读/写锁允许同时有多个读者，但前提是没有作者已经在。因此在某些使用场景下我们可以获得更好的并发性，因为读者群体可以一起进行。
Java API documentationgives the example of collection classes which are expected to have more readers than writers.
Java API文档给出了一个集合类的例子，这些类的读者比作者多。
回答by Sanjay T. Sharma
The locking article by Brianexplains in detail the pros and cons of each approach.
The Lock framework is a compatible replacement for synchronization, which offers many features not provided by synchronized, as well as implementations offering better performance under contention. However, the existence of these obvious benefits are not a good enough reason to always prefer ReentrantLock to synchronized. Instead, make the decision on the basis of whether you need the power of ReentrantLock. In the vast majority of cases, you will not -- synchronization works just fine, works on all JVMs, is understood by a wider range of developers, and is less error-prone. Save Lock for when you really need it. In those cases, you'll be glad you have it.
Lock 框架是同步的兼容替代品，它提供了许多同步所没有的特性，以及在争用情况下提供更好性能的实现。然而，这些明显的好处的存在并不能成为总是喜欢 ReentrantLock 而不是同步的充分理由。相反，根据您是否需要 ReentrantLock 的功能来做出决定。在绝大多数情况下，您不会——同步工作得很好，适用于所有 JVM，被更广泛的开发人员理解，并且不易出错。在您真正需要时保存 Lock。在这些情况下，您会很高兴拥有它。
回答by Chai T. Rex
It should be noted that StampedLockhas since come out with Java 8, and it's much faster than ReentrantReadWriteLock(especially as you use more and more threads) when you don't use the lock in a reentrant manner (using StampedLockreentrantly can lead to deadlocks, so don't do it).
应该注意的是StampedLock，自 Java 8 以来，它比ReentrantReadWriteLock不以可重入方式使用锁（使用StampedLock可重入会导致死锁，所以不要不做）。
It also allows optimistic read nonlocks that are available if there is no write lock in effect. Unlike a normal read lock, they don't block a write lock from being established. You can check whether a write lock has been established over your optimistic read nonlock by using the validatemethod.
如果没有有效的写锁，它还允许使用乐观读非锁。与普通的读锁不同，它们不会阻止写锁的建立。您可以通过使用检查是否写锁已经在你的乐观读取非锁定已建立的validate方法。
Its interface is a little different since you have to store a longvalue called a stamp in order to later unlock a read or write lock properly or to later validatean optimistic read nonlock properly when you're done.
它的接口有点不同，因为您必须存储一个long称为标记的值，以便以后正确解锁读或写锁，或者在完成后正确解锁validate乐观读非锁。
