Múltiples hilos que iteran en el mismo mapa

Question

Hace poco escribí un programa simultáneo en Java y encontré el dilema de seguimiento: supongamos que tiene una estructura de datos global, que es parte de lib no concurrente regular, como HashMap. ¿Está bien permitir que múltiples hilos iteren a través de la colección (solo lectura, sin modificaciones) tal vez en diferentes períodos intercalados, es decir, thread1 podría estar a mitad de camino iterando cuando thread2 obtiene su iterador en el mismo mapa?

Answer 1

Está bien. La capacidad de hacer esto es la razón para crear dicha interfaz como iterador. Cada hilo que itera sobre la colección tiene su propia instancia de iterador que mantiene su estado (por ejemplo, donde se encuentra ahora en su proceso de iteración).

Esto permite que varios hilos iteren sobre la misma colección simultáneamente.

Answer 2

Los problemas solo surgen cuando intenta modificaciones simultáneas en una estructura de datos.

Por ejemplo, si un hilo se itera sobre el contenido de un mapa, y otro hilo elimina elementos de esa colección, se dirigirá a un problema grave.

Si necesita algunos subprocesos para modificar esa colección de forma segura, Java proporciona mecanismos para hacerlo, es decir, ConcurrentHashMap.

ConcurrentHashMap in Java?

También hay Hashtable, que tiene la misma interfaz que HashMap, pero está sincronizada, aunque su uso no se recomienda actualmente (en desuso), ya que es el rendimiento se resiente cuando el número de elementos se hace más grande (en comparación a ConcurrentHashMap que no necesita bloquear toda la Colección).

Si tiene una colección que no está sincronizada y necesita tener varios hilos para leer y escribir sobre ella, puede usar Collections.synchronizedMap (Map) para obtener una versión sincronizada de la misma.

Answer 3

Debería estar bien, siempre y cuando no haya escritores.

Este problema es similar al readers-writer lock, donde varios lectores pueden leer los datos, pero no durante el tiempo que un escritor "tiene" el bloqueo. No hay problemas de concurrencia para lecturas múltiples al mismo tiempo. [data race puede ocurrir solo cuando tiene al menos una escritura].

Answer 4

Las respuestas anteriores son sin duda un buen consejo. En general, al escribir Java con subprocesos concurrentes, siempre que no modifique una estructura de datos, no tiene que preocuparse de que varios subprocesos lean dicha estructura simultáneamente.

En caso de que tenga un problema similar en el futuro, excepto que la estructura de datos global podría modificarse simultáneamente, sugeriría escribir una clase Java que todos los hilos usen para acceder y modificar la estructura. Esta clase podría implementar su propia metodología de simultaneidad, utilizando métodos sincronizados o bloqueos. El tutorial de Java tiene una muy buena explicación de los mecanismos de concurrencia de Java. Yo personalmente he hecho esto y es bastante sencillo.