Vous avez besoin d'une map partagée par de nombreux threads. Qu'utilisez-vous, et que fait ConcurrentHashMap qu'une map synchronisée ne fait pas ?

Utilisez ConcurrentHashMap. Elle verrouille par bin plutôt que la map entière, avec un compare-and-set pour les bins vides et une synchronisation sur la tête du bin sinon, si bien que les lecteurs ne bloquent jamais et que les écritures dans des bins différents avancent en parallèle. Une map synchronisée sérialise chaque opération sur un seul verrou, et elle exige quand même une synchronisation externe pendant l'itération. Utilisez ses méthodes atomiques, comme compute et merge, plutôt qu'un get suivi d'un put.

ConcurrentHashMap, presque toujours. La différence importante est la granularité : elle verrouille au niveau d'un seul bin, et une insertion dans un bin vide n'est qu'un compare-and-set, donc des clés sans rapport n'entrent pas en contention et les lectures sont sans verrou. Une map synchronisée met un verrou unique autour de tout, donc elle devient le goulet dès que plusieurs threads travaillent. Le plus gros piège avec un wrapper synchronisé, c'est que les appels individuels sont atomiques mais pas les séquences : si je teste containsKey puis que je fais put, un autre thread peut se glisser entre les deux, et l'itération n'est pas sûre du tout si je ne tiens pas le verrou moi-même. C'est pour ça que j'utilise les méthodes atomiques : computeIfAbsent pour une entrée de cache construite paresseusement, merge pour des compteurs, comme ça la lecture-modification-écriture se passe à l'intérieur de la map. Les choses à savoir : size est une estimation en cas de modification concurrente et les itérateurs sont faiblement cohérents, donc ils ne lèvent pas d'exception mais peuvent ne pas voir les écritures les plus récentes. Pour d'autres formes j'utilise CopyOnWriteArrayList quand les lectures dépassent largement les écritures, et une BlockingQueue pour le passage de main entre producteur et consommateur.