He leído en algún lugar que en ConcurrentHashMap, el objeto de mapa completo no está bloqueado y en su lugar se realiza un bloqueo en una parte del Mapa.ConcurrentHashMap bloqueo
¿Puede alguien explicar cuándo entra el bloqueo en la imagen?
¿Es correcto que durante la lectura del Mapa no haya ningún bloqueo involucrado pero al actualizarlo solo se utiliza el bloqueo?
Sí, ConcurrentHashMap utiliza una multitud de bloqueos, cada bloqueo controla un segmento del hash.
Al configurar datos en un segmento particular, se obtiene el bloqueo para ese segmento.
Al obtener datos, se usa una lectura volátil. Si la lectura volátil da como resultado una falla, el bloqueo para el segmento se obtiene para un último intento de lectura exitosa.
No recibí "si el Si la lectura volátil da como resultado una falla, entonces el bloqueo para el segmento se obtiene para un último intento de una lectura exitosa". ¿Puedes explicarnos poco en detalle? – Anand
@anand De acuerdo con el JMM, es posible que la escritura volátil de un campo en el constructor sea visible para los hilos una vez que el objeto termina la construcción y es visible para otros hilos (esto no es cierto para los campos finales). El bloqueo al que se refiere asegurará que suceda, antes de ordenar esa escritura volátil de otras lecturas. Nota: Esto pudo ocurrir, aunque nunca lo haya hecho, y nunca lo he leído en Java 6; se habló de eliminarlo por la confusión. –
Y solo para aclarar que la finalización del constructor se refiere a la entrada del cubo. –
El bloqueo se minimiza tanto como sea posible sin dejar de ser thread-safe.
Para explicar "parte del Mapa está bloqueado", esto significa que al actualizar, solo se bloquea un "1/concurrencyLevel" del Mapa (basado en un hash de la clave). Esto significa que dos actualizaciones pueden ejecutarse simultáneamente de manera segura si cada una de ellas afecta a "cubos" separados, lo que minimiza la contención de bloqueos y así maximiza el rendimiento.
Más importante aún, confíe en la implementación de JDK; no debería tener que preocuparse por los detalles de implementación en el JDK (por un lado, puede cambiar de versión a versión). Más bien, solo concéntrese en escribir su código.
Cuando vincula Hashtable, ¿quiere decir ConcurrentHashMap? Tu explicación es incorrecta de lo contrario. Toda la instancia de Hashtable está sincronizada para cualquier modificación o lectura. –
@JohnVint Gracias. Actualicé mi respuesta. – Bohemian
@trutheality Gracias. Corregí mi respuesta. – Bohemian
ConcurrentHashMap use Mecanismo de bloqueo de reentrada. ConcurrentHashMap usa segmentos en lugar de cubos y cuando se obtiene un nuevo registro, el bloqueo de inserción solo se obtendrá en el segmento, no en la lista completa de segmentos. Así que aquí la idea deja en claro que el bloqueo de varios niveles se adquirirá de la misma manera.
Como no se ha establecido un nivel de concurrencia explícita, el ConcurrentHashMap se divide en 16 segmentos. Y cada segmento actúa como un HashMap independiente.
No se aplica bloqueo en la operación de lectura en ConcurrentHashMap.
este artículo debería ayudar: http://www.ibm.com/developerworks/java/library/j-jtp08223/ – yegor256
The [javadoc] (http://docs.oracle.com/javase/7/docs/ api/java/util/concurrent/ConcurrentHashMap.html) es bastante detallado al explicar la implementación. – trutheality