在不鼓励使用诸如Hashtable和Vector之类的东西之后，当出现Collections同步包装器时，我认为同步将得到更有效的处理。现在，我研究了代码，我很惊讶它确实只是用同步块(synchronized block)包装了集合。
为什么ReadWriteLock不包含在例如Collections中的SynchronizedMap中？有一些效率方面的考虑不值得吗？
最佳答案
读写锁是性能优化的一部分，这意味着在某些情况下，它可以允许更大的并发性。必要条件是，将它们应用于大多数时间都是，但未经修改的读取的数据结构。
在其他条件下，它们的性能比排他锁稍差一些，这很自然，因为它们的复杂性更高。
如果读写锁的锁通常保持适当长的时间，并且仅对 protected 资源进行很少的修改，这将是最有效的。
因此，读写锁是否优于排他锁取决于用例。最终，您必须通过性能分析来衡量哪些锁的性能更好。
考虑到这一点，为Collections.synchronizedMap选择一个专用锁来解决一般用例而不是针对大多数读者的特殊用例似乎是合适的。
进一步链接
他们编写了一个工具，可以在适当的情况下将Java应用程序中的锁自动转换为ReentrantLocks和ReadWriteLocks。为了进行测量，他们还提供了一些有趣的基准测试结果: