Necesitas un mapa compartido por muchos hilos. ¿Qué usas, y qué hace ConcurrentHashMap que no haga un mapa sincronizado?

Usa ConcurrentHashMap. Bloquea por bin en vez de bloquear el mapa entero, con un compare and set para los bins vacíos y sincronizando sobre la cabeza del bin en el resto de casos, así que los lectores nunca se bloquean y las escrituras en bins distintos avanzan en paralelo. Un mapa sincronizado serializa cada operación sobre un único lock, y encima sigue necesitando sincronización externa al iterar. Usa sus métodos atómicos, como compute y merge, en lugar de un get seguido de un put.

ConcurrentHashMap, casi siempre. La diferencia importante es la granularidad: bloquea al nivel de un solo bin, y una inserción en un bin vacío es solo un compare and set, así que las claves no relacionadas no compiten y las lecturas van sin lock. Un mapa sincronizado pone un único lock alrededor de todo, así que se convierte en el cuello de botella en cuanto hay varios hilos ocupados. La trampa mayor del envoltorio sincronizado es que las llamadas individuales son atómicas pero las secuencias no, así que si compruebo containsKey y luego hago put, otro hilo puede colarse en medio, y la iteración directamente no es segura si no sostengo yo el lock. Por eso uso los métodos atómicos: computeIfAbsent para una entrada de caché construida de forma perezosa, merge para contadores, de modo que la lectura, modificación y escritura ocurra dentro del mapa. Lo que hay que saber es que size es una estimación bajo modificación concurrente y que los iteradores son débilmente consistentes, así que no lanzan pero pueden no ver las escrituras más nuevas. Para otras formas uso CopyOnWriteArrayList cuando las lecturas superan de largo a las escrituras, y una BlockingQueue para el traspaso entre productor y consumidor.