ConcurrentHashMap の実装では、ReentrantLock が既に使用されていると思います。そのため、ConcurrentHashMap オブジェクトへのアクセスに ReentrantLock を使用する必要はありません。そして、それは同期のオーバーヘッドを増やすだけです。コメントはありますか？
2687 次
2 に答える
10
あなた（または誰か）はそれで何を達成したいですか？ConcurrentHashMapそのままですでにスレッドセーフです。追加のロック コードでラップすると、大幅に遅くなるだけです。
- 読み取り自体はロックしません。
- 書き込みの場合でも、内部ロックのパーティション分割動作を外部で模倣することはほとんどできません。
つまり、余分なロックを追加すると、スレッドの競合の可能性が大幅に増加します (また、記録のために、読み取り操作のスレッドの安全性の保証がより厳しくなります)。
ConcurrentHashMapの実装をConcurrentMap提供し、スループットとスレッド セーフを調整する問題に対する非常に効果的なソリューションを提供します。読み取り用に最適化されているため、テーブルが更新されている間でも取得がブロックされません (これを可能にするために、取得の開始前に完了した最新の更新操作が取得の結果に反映されることが契約で規定されています)。多くの場合、更新はブロックせずに続行できますConcurrentHashMap。これは、 が 1 つではなく、セグメントと呼ばれる一連のテーブルで構成され、それぞれが個別にロックできるためです。セグメントの数が、テーブルにアクセスするスレッドの数に対して十分に大きい場合、多くの場合、進行中の更新は常にセグメントごとに 1 つしかありません。
Java Generics and Collections の 16.4 章から。
于 2010-10-14T15:49:36.300 に答える
5
ConcurrentHashMap の要点は、アクセス/変更をロックすることではありません。追加のロックはオーバーヘッドを追加するだけです。
于 2010-10-14T15:46:34.697 に答える