java - 为什么 Java 的同步集合不使用读/写锁？

Question

在像 Hashtable 和 Vector 这样的东西被劝阻之后，当集契约(Contract)步包装器出现时，我认为同步处理会更有效。现在我查看了代码，我很惊讶它真的只是用同步块(synchronized block)包装集合。

为什么 ReadWriteLock 没有包含在集合中，例如 SynchronizedMap？是否有一些不值得的效率考虑？

Answer 1

读写锁是性能优化的一部分，这意味着它可以在某些情况下允许更大的并发。必要条件是，它们应用于大部分时间读取但未修改的数据结构。

在其他条件下，它们的性能略低于排他锁，这是自然而然的，因为它们具有更高的复杂性。

如果读写锁的锁通常保持适当长的时间并且只对 protected 资源进行少量修改，则效率最高。

因此，读写锁是否优于排他锁取决于用例。最终，您必须通过分析来衡量哪些锁的性能更好。

考虑到这一点，为 Collections.synchronizedMap 选择独占锁似乎更适合解决一般用例，而不是大多数读者的特殊情况。

更多链接

• Starvation with ReadWriteLocks

• Refactoring Java Programs for Flexible Locking

  他们编写了一个工具，可以在适当的时候自动将 Java 应用程序中的锁转换为 ReentrantLocks 和 ReadWriteLocks。出于衡量目的，他们还提供了一些有趣的基准测试结果:

[...] However, in a configuration where write operations were more prevalent, the version with synchronized blocks was 50% faster than one based on read-write locks with the Sun 1.6.0_07 JVM (14% faster with the Sun 1.5.0_15 JVM).

In a low-contention case with just 1 reader and 1 writer, the performance differences were less extreme, and each of the three types of locks yielded the fastest version on at least one machine/VM configuration (e.g., note that ReentrantLocks were fastest on the 2-core machine with the Sun 1.5.0_15 JVM).