Você precisa de um mapa compartilhado por muitas threads. O que você usa, e o que o ConcurrentHashMap faz que um mapa sincronizado não faz?

Use ConcurrentHashMap. Ele trava por bin em vez do mapa inteiro, usando um compare and set para bins vazios e sincronizando na cabeça do bin nos outros casos, então leitores nunca bloqueiam e escritores em bins diferentes seguem em paralelo. Um mapa sincronizado serializa toda operação num único lock, e ainda exige sincronização externa durante a iteração. Use os métodos atômicos dele, como compute e merge, em vez de get seguido de put.

ConcurrentHashMap, quase sempre. A diferença importante é granularidade: ele trava no nível de um único bin, e uma inserção num bin vazio é só um compare and set, então chaves não relacionadas não competem e as leituras são livres de lock. Um mapa sincronizado coloca um lock em volta de tudo, então ele vira o gargalo assim que várias threads ficam ocupadas. A armadilha maior com um wrapper sincronizado é que chamadas individuais são atômicas mas sequências não são, então se eu checo containsKey e depois faço put, outra thread pode se enfiar entre as duas, e a iteração não é segura de jeito nenhum sem eu segurar o lock. É por isso que eu uso os métodos atômicos: computeIfAbsent para uma entrada de cache construída sob demanda, merge para contadores, para que o ler, modificar e escrever aconteça dentro do mapa. As coisas que dá para saber são que size é uma estimativa sob modificação concorrente e que os iteradores são fracamente consistentes, então eles não lançam mas podem não ver as escritas mais novas. Para outros formatos eu uso CopyOnWriteArrayList quando as leituras superam de longe as escritas, e uma BlockingQueue para repasse entre produtor e consumidor.