Es seguro obtener valores de un java.útil.HashMap de múltiples hilos (sin modificación)?

Jeremy Manson, el dios cuando se trata del Modelo de Memoria Java, tiene un blog de tres partes sobre este tema - porque en esencia usted está haciendo la pregunta "Es seguro acceder a un HashMap inmutable" - la respuesta a eso es sí. Pero debe responder el predicado a esa pregunta que es - "Es mi HashMap inmutable". La respuesta podría sorprenderte - Java tiene un conjunto relativamente complicado de reglas para determinar la inmutabilidad.

Para obtener más información sobre el tema, lea el blog de Jeremy mensajes:

Parte 1 sobre la inmutabilidad en Java: http://jeremymanson.blogspot.com/2008/04/immutability-in-java.html

Parte 2 sobre la inmutabilidad en Java: http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html

Parte 3 sobre la inmutabilidad en Java: http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html

Las lecturas son seguras desde el punto de vista de la sincronización, pero no desde el punto de vista de la memoria. Esto es algo que es ampliamente mal entendido entre los desarrolladores de Java, incluyendo aquí en Stackoverflow. (Observe la calificación de esta respuesta como prueba.)

Si tiene otros subprocesos en ejecución, es posible que no vean una copia actualizada del HashMap si no hay escritura de memoria fuera del subproceso actual. Las escrituras de memoria se producen mediante el uso de palabras clave sincronizadas o volátiles, o mediante el uso de algunas construcciones de simultaneidad de Java.

Ver El artículo de Brian Goetz sobre el nuevo Modelo de Memoria Java para más detalles.

Después de mirar un poco más, encontré esto en el java doc (énfasis mío):

Tenga en cuenta que esta implementación no es sincronizar. Si hay varios hilos acceder a un mapa hash simultáneamente, y en al menos uno de los hilos modifica el mapa estructural, debe ser sincronizado externamente. (Una estructura modificación es cualquier operación que añade o elimina una o más asignaciones; simplemente cambiando el valor asociado con una clave que una instancia ya contiene no es una estructura modificación.)

Esto parece implicar que será seguro, asumiendo que el inverso de la declaración allí es verdadero.

Una nota es que bajo algunas circunstancias, un get() de un HashMap no sincronizado puede causar un bucle infinito. Esto puede ocurrir si un put () simultáneo causa una repetición del mapa.

Http://lightbody.net/blog/2005/07/hashmapget_can_cause_an_infini.html

Sin embargo, hay un giro importante. Es seguro acceder al mapa, pero en general no se garantiza que todos los subprocesos verán exactamente el mismo estado (y por lo tanto los valores) del HashMap. Esto puede suceder en sistemas multiprocesadores donde las modificaciones al HashMap hechas por un subproceso (por ejemplo, el que lo llenó) pueden estar en la caché de esa CPU y no serán vistas por subprocesos que se ejecutan en otras CPU, hasta que se realice una operación de valla de memoria que garantice la coherencia de la caché. El Lenguaje Java La especificación es explícita en este caso: la solución es adquirir un bloqueo (sincronizado (...)) que emite una operación de valla de memoria. Por lo tanto, si está seguro de que después de rellenar el HashMap cada uno de los hilos adquiere CUALQUIER bloqueo, entonces está bien a partir de ese punto para acceder al HashMap desde cualquier hilo hasta que el HashMap se modifica de nuevo.

Según http://www.ibm.com/developerworks/java/library/j-jtp03304 / # Seguridad de inicialización puede hacer que su HashMap sea un campo final y después de que el constructor termine, se publicará de forma segura.

... Bajo el nuevo modelo de memoria, hay algo similar a una relación sucede-antes entre la escritura de un campo final en un constructor y la carga inicial de una referencia compartida a ese objeto en otro hilo. ...

Así que el escenario que estás describiendo es que necesitas poner un montón de datos en un mapa, luego cuando termines de poblarlo lo tratas como inmutable. Un enfoque que es "seguro" (lo que significa que está imponiendo que realmente se trata como inmutable) es reemplazar la referencia con Colecciones.Mapa no modificable (mapa original) cuando esté listo para hacerlo inmutable.

Para ver un ejemplo de lo mal que los mapas pueden fallar si se usan simultáneamente, y la solución sugerida que mencioné, echa un vistazo a esto entrada del desfile de errores: bug_id=6423457

Ser advertido de que, incluso en un único subproceso código, la sustitución de un ConcurrentHashMap con un HashMap pueden no ser seguros. ConcurrentHashMap prohíbe null como clave o valor. HashMap no les prohíbe (no pregunte).

Por lo tanto, en la improbable situación de que su código existente pueda agregar un null a la colección durante la configuración (presumiblemente en un caso de error de algún tipo), reemplazar la colección como se describe cambiará el comportamiento funcional.

Dicho esto, siempre que no hagas nada más las lecturas simultáneas de un HashMap son seguras.

[Editar: por "lecturas concurrentes", quiero decir que no hay también modificaciones concurrentes.

Otras respuestas explican cómo asegurar esto. Una forma es hacer que el mapa sea inmutable, pero no es necesario. Por ejemplo, el modelo de memoria JSR133 define explícitamente iniciar un subproceso como una acción sincronizada, lo que significa que los cambios realizados en el subproceso A antes de que inicie el subproceso B son visibles en el subproceso B.

Mi intención no es contradecir a los respuestas más detalladas sobre el Modelo de Memoria Java. Esta respuesta tiene la intención de señalar que incluso aparte de los problemas de concurrencia, hay al menos una diferencia de API entre ConcurrentHashMap y HashMap, que podría echar por tierra incluso un programa de un solo subproceso que reemplazó a uno con el otro.]

Http://www.docjar.com/html/api/java/util/HashMap.java.html

Aquí está la fuente para HashMap. Como puede ver, no hay absolutamente ningún código de bloqueo / mutex allí.

Esto significa que si bien está bien leer desde un HashMap en una situación multiproceso, definitivamente usaría un ConcurrentHashMap si hubiera varias escrituras.

Lo interesante es que tanto la tabla HashTable.NET como el Diccionario han incorporado código de sincronización.

Si la inicialización y cada put está sincronizada, está guardado.

El siguiente código se guarda porque el classloader se encargará de la sincronización:

public static final HashMap<String, String> map = new HashMap<>();
static {
  map.put("A","A");

}

El siguiente código se guarda porque la escritura de volatile se encargará de la sincronización.

class Foo {
  volatile HashMap<String, String> map;
  public void init() {
    final HashMap<String, String> tmp = new HashMap<>();
    tmp.put("A","A");
    // writing to volatile has to be after the modification of the map
    this.map = tmp;
  }
}

Esto también funcionará si la variable miembro es final porque final también es volátil. Y si el método es un constructor.