Aus meiner Sicht bietet eine gleichzeitige Hash-Map ab Java 5 eine threadsichere Hash-Map, die keinen blockierenden Zugriff für Iteratoren und Aktualisierungen verwendet (wenn eine Parallelitätsebene ausreicht).
Gegeben die folgenden Bedingungen:
würde ich mit einfachen Hash-Karten besser dran sein?
Mein Verständnis ist, dass ich wahrscheinlich besser dran bin, weil meine Schlüssel nicht kollidieren werden - das kann ich garantieren. Aber ist es möglich, dass die Java-Implementierung Dinge in den Hash-Buckets vermasselt, indem man beispielsweise denselben Bucket zwei verschiedenen Schlüsseln zuweist?
Wenn Sie mehrere Threads einfügen, auch wenn die Schlüssel unterschiedlich sind, sollten Sie unbedingt ConcurrentHashMap verwenden oder die Einfügungen synchronisieren. Plain HashMap ist einfach nicht sicher für gleichzeitige Schreibvorgänge. Angenommen, zwei Threads müssen jeweils gleichzeitig die interne Tabelle erweitern ... obwohl sie unterschiedliche Schlüssel verwenden, ist das eine grundsätzlich problematische Situation.
Nun, wenn Sie wirklich wirklich gute Beweise dafür haben, dass die Verwendung von ConcurrentHashMap für den Rest Ihrer Lebenszeit ein Problem verursacht (und ich bezweifle, dass es das tut), könnten Sie vielleicht ein Parallele Hash-Map, mit der Sie beginnen können, konvertieren Sie sie in ein HashMap (oder sogar eine unveränderliche Sammlung von Guava ) in einem einzigen Thread , stellen Sie sicher, dass es eine Vor-Vor-Grenze zwischen "endgültige Karte ist veröffentlicht" und "Fäden lesen endgültige Karte" gibt.
Wenn Sie über Threads hinweg unabhängige Schlüssel haben, können Sie unabhängige Maps in Betracht ziehen. Wenn dies eine Option ist, kann jeder Thread seine eigene HashMap haben, die nicht threadsicher sein muss, vorausgesetzt, dass sie nur von einem Thread verwendet wird.
Tags und Links java concurrency hashmap