用ReentrantLock包装ConcurrentHashMap读写操作是一个好习惯吗?

dli*_*liu 3 java concurrency concurrenthashmap reentrantreadwritelock

我认为在ConcurrentHashMap的实现中,已经使用了ReentrantLock.因此,不需要使用ReentrantLock来访问ConcurrentHashMap对象.这只会增加更多的同步开销.任何意见?

Pét*_*rök 10

你(或任何人)想要用它做什么?ConcurrentHashMap已经是线程安全的了.用额外的锁定代码包装它只会显着减慢它的速度,因为

  1. 它不会锁定读取本身,
  2. 即使是写入,您也很难在外部模仿其内部锁定分区行为.

换句话说,添加额外的锁定会显着增加线程争用的可能性(以及使记录的读取操作的线程安全保证更严格).

ConcurrentHashMap提供了一种实现方法,ConcurrentMap并为解决吞吐量与线程安全性的问题提供了一种高效的解决方案.它针对读取进行了优化,因此即使在更新表时,检索也不会阻塞(为此,合同规定检索结果将反映在检索开始之前完成的最新更新操作).更新通常也可以不受阻塞地进行,因为一个ConcurrentHashMap表不是一个而是一组表,称为段,每个表都可以独立锁定.如果段的数量相对于访问表的线程数足够大,则每个段通常不会有多于一个正在进行的更新.

来自Java Generics and Collections,第16.4节.


Mic*_*eyn 5

ConcurrentHashMap的重点不在于锁定对它的访问/修改.额外的锁定只会增加开销.