Concurrenthashmap (CHM para abreviar) se introdujo recientemente en Java 1.5 como una alternativa a la hashtable y es un miembro importante del paquete concurrente. Antes de Java 1.5, si desea implementar un mapa que se pueda usar de forma segura en programas multi-subprocesos y concurrentes, solo puede elegir entre el mapa hashtable y sincronizado, porque HASHMAP no es seguro de hilo. Pero después de introducir CHM, tenemos una mejor opción. CHM no solo es seguro de hilo, sino que también funciona mejor que el mapas de hashtable y sincronizado. En comparación con el mapas hashtable y sincronizado, todo el mapa está bloqueado, y CHM solo bloquea algunos mapas. CHM permite operaciones de lectura concurrentes mientras se mantiene la integridad de los datos durante las operaciones de escritura a través de bloqueos sincrónicos. Hemos aprendido los conceptos básicos de CHM en las 5 principales colecciones concurrentes de Java de JDK 5 y 6. En este blog presentaré los siguientes puntos:
Implementación de concurrenthashmap en Java
CHM presenta la segmentación y proporciona todas las características admitidas por Hashtable. En CHM, MultithReading es compatible con el mapa de lectura y no requiere ningún bloqueo. Esto se debe al hecho de que CHM divide el mapa en diferentes partes, bloqueando solo parte de él al realizar la operación de actualización. De acuerdo con el nivel de concurrencia predeterminado, el mapa se divide en 16 partes y está controlado por diferentes bloqueos. Esto significa que hasta 16 hilos de escritura pueden operar el mapa al mismo tiempo. Imagine que desde un solo hilo ingresa a 16 hilos de escritura que ingresan al mismo tiempo (los hilos de lectura son casi ilimitados), la mejora del rendimiento es obvia. Sin embargo, dado que algunas operaciones de actualización, como PUT (), Remove (), Putall () y Clear (), solo bloquean la operación, la operación de búsqueda no puede garantizar que se devuelvan los últimos resultados.
Otro punto importante es que al iterar sobre CHM, el iterador devuelto por KeySet es débilmente consistente y a prueba de fallas, y puede no devolver algunos cambios recientes. Durante el recorrido, si el contenido en la matriz que ha sido atravesado cambia, no se lanzará la excepción de modificación concurrente.
El nivel de concurrencia predeterminado de CHM es 16, pero un constructor puede cambiarlo al crear CHM. No hay duda de que el nivel de concurrencia representa el número de operaciones de actualización concurrentes, por lo que si solo unos pocos hilos actualizarán el mapa, se recomienda establecer un nivel de concurrencia bajo. Además, CHM también usa ReentrantLock para bloquear segmentos.
Ejemplo del método de Putifabsent de Concurrenthashmap en Java
Muchas veces queremos insertar elementos cuando no existen, y generalmente escribimos código como el siguiente
sincronizado (map) {if (map.get (key) == null) {return map.put (clave, valor); } else {return map.get (clave); }}El código anterior es fácil de usar en hashmap y hashtable, pero existe el riesgo de errores en CHM. Esto se debe a que CHM no bloquea todo el mapa durante la operación de colocación, por lo que cuando se coloca un hilo (k, v), otra hilo las llamadas obtienen (k) y se vuelven nulo, lo que hará que el valor de un hilo se sobrescriba por el valor de otro hilo. Por supuesto, puede encapsular el código en un bloque de código sincronizado, lo que hará que su código sea un solo hilo, aunque ausente de subprocesos. El método Putifabsent (clave, valor) proporcionado por CHM implementa la misma función atómicamente, al tiempo que evita el riesgo de competencia de hilos anteriores.
Cuándo usar concurrenthashmap
CHM es adecuado para cuando el número de lectores excede el número de lectores, y cuando el número de lectores es mayor o igual al lector, el rendimiento de CHM es más bajo que el del mapa hashtable y sincronizado. Esto se debe a que cuando todo el mapa está bloqueado, la operación de lectura espera el hilo que realiza la operación de escritura a la misma parte. CHM es adecuado para hacer caché, inicializado al comienzo del programa y luego se puede acceder mediante múltiples subprocesos solicitantes. Como explica Javadoc, CHM es una buena alternativa al hashtable, pero recuerde que CHM tiene un poco menos de sincronización que la hashtable.
Resumir
Ahora sabemos qué es concurrenthashmap y cuándo usar concurrenthashmap. Revisemos algunos puntos clave de CHM.
Lo anterior son los escenarios de implementación y uso de CHM en Java, ¡espero que pueda ayudar a todos! ¡Gracias por su apoyo a este sitio!