Du brauchst eine Map, die sich viele Threads teilen. Was nimmst du, und was macht ConcurrentHashMap, was eine synchronized Map nicht macht?

Nimm ConcurrentHashMap. Sie sperrt pro Bin statt der ganzen Map, mit einem Compare-and-Set für leere Bins und sonst Synchronisation auf dem Bin-Kopf, Leser blockieren also nie und Schreiber in verschiedenen Bins laufen parallel. Eine synchronized Map serialisiert jede Operation über ein einziges Lock, und beim Iterieren brauchst du trotzdem externe Synchronisation. Nutz ihre atomaren Methoden wie compute und merge statt get gefolgt von put.

ConcurrentHashMap, fast immer. Der wichtige Unterschied ist die Granularität: sie sperrt auf der Ebene eines einzelnen Bins, und ein Insert in einen leeren Bin ist nur ein Compare-and-Set, unabhängige Keys konkurrieren also nicht und Lesezugriffe sind lock-frei. Eine synchronized Map legt ein Lock um alles, sie wird also zum Flaschenhals, sobald mehrere Threads beschäftigt sind. Die größere Falle bei einem synchronized Wrapper ist, dass einzelne Aufrufe atomar sind, Folgen davon aber nicht, prüfe ich also containsKey und mache dann put, kann ein anderer Thread dazwischenrutschen, und Iteration ist ohne eigenes Halten des Locks gar nicht sicher. Deshalb nutze ich die atomaren Methoden: computeIfAbsent für einen faul gebauten Cache-Eintrag, merge für Zähler, damit das read-modify-write innerhalb der Map passiert. Wissen sollte man, dass size unter nebenläufiger Änderung eine Schätzung ist und Iteratoren schwach konsistent sind, sie werfen also nicht, sehen aber vielleicht nicht die neuesten Writes. Für andere Formen nehme ich CopyOnWriteArrayList, wenn Lesezugriffe die Schreibzugriffe weit übersteigen, und eine BlockingQueue für die Übergabe zwischen Producer und Consumer.