5

Necesito un HashMap al que se pueda acceder desde varios hilos.¿Hay algún inconveniente con ConcurrentHashMap?

Hay dos opciones simples, utilizando un HashMap normal y la sincronización en él o utilizando un ConcurrentHashMap.

Desde ConcurrentHashMap no bloquea en las operaciones de lectura parece mucho más adecuado para mis necesidades (lee casi exclusivamente, casi nunca se actualiza). Por otro lado, espero concurrencia muy baja de todos modos, por lo que no debería haber ningún bloqueo (solo el costo de administrar el bloqueo).

El mapa también será muy pequeño (menos de diez entradas), si eso hace la diferencia.

En comparación con un HashMap regular, cuánto más costosos son los de lectura y escritura (estoy asumiendo que son)? ¿O es que ConcurrentHashMap siempre es mejor cuando puede haber incluso un nivel moderado de acceso concurrente, independientemente de la relación de lectura/actualización y el tamaño?

+0

pregunta duplicado exacto? http://stackoverflow.com/questions/1378310/performance-concurrenthashmap-vs-hashmap – andersoj

+0

De hecho. Gracias.(Sin embargo, aún no hay una respuesta satisfactoria) – Thilo

Respuesta

6

Por otro lado, espero concurrencia muy baja de todos modos, por lo que no debe haber bloqueo (solo el costo de administrar el bloqueo).

El coste de adquisición y liberación de un uncontend Java mutex (bloqueo primitivo) es minúsculo. Entonces, si crees que la probabilidad de contención es muy baja, entonces una simple HashMap es probablemente tu mejor opción.

Pero esto es todo conjetura. A menos que, y hasta que haya diseñado su aplicación, todo el tiempo invertido en la optimización especulativa probablemente se pierda (*) en el tiempo.

* ... a menos que tengas realmente buena intuición.

+0

Stephen C tiene razón (su representante sugiere que esto es un hábito). Los bloqueos incontrolados son rápidos en el caso general ... Termino buscando CHM demasiado rápido, quizás. – andersoj

+0

¿Qué pasa con la escala? Lo que se espera y lo que podría pasar son completamente diferentes. Si el bloqueo/desbloqueo es muy pequeño, simplemente use 'ConcurrentHashMap' y continúe con – TheLQ

+1

@TheLQ; estos son los otros gastos generales (aparte del bloqueo) de usar ConcurrentHashMap que son la preocupación. No solo lanza CCM a un problema en el supuesto de que la escalabilidad * será * un problema. ¡Mides primero! –

2

CHM paga alguna penalización por el uso de operaciones Atómica * bajo las sábanas, en comparación con HashMap. ¿Cuánto cuesta? Adivina qué ... mídelo en tu aplicación ... ;-)

Si encuentras que realmente tienes un problema de rendimiento, probablemente haya una solución muy especializada para < 10 entradas que serían más baratas que cualquier solución ensamblada de java.util terreno, pero no me atrevería a hacerlo hasta que sepa que tiene un problema de rendimiento.

+0

La pregunta que tengo es si debería pasar a usar ConcurrentHashMap antes de saber que tengo un problema de rendimiento. No me gustaría hacer eso si CHM fuera más lento que HashMap en el caso de no concurrencia. – Thilo

+0

Supongo que usaría 'CHM' si es inmediatamente evidente que puede obtener el control de concurrencia que desee con w /' putIfAbsent() 'y similares; Usaría 'synchronized (normalHashMap)' si sabes de antemano que la operación 'put()' va a ser compleja. (Optimizando uno más adelante si es un problema ...) – andersoj

2

en términos de rendimiento y el rendimiento, la sobrecarga es generalmente despreciable.

En una nota diferente, la huella de memoria de un ConcurrentHashMap (a nivel de instancia) es algo mayor que un HashMap. Si tiene una gran cantidad de CHM de pequeño tamaño, esta sobrecarga puede sumarse.

Cuestiones relacionadas