Estoy realmente confundido sobre cómo estas 2 colecciones se comportan en un entorno multiproceso.Hashmap y hashtable en el entorno multiproceso
mesaHash está sincronizado que significa que no hay 2 hilos van a actualizar su valor al mismo tiempo ¿verdad?
Exactamente, HashTable está sincronizado, lo que significa que es seguro usarlo en entornos multihilo (muchos hilos tienen acceso a la misma tabla Hash) Si dos hilos intentan actualizar la tabla hash al mismo tiempo, uno de ellos tendrá que esperar que el otro hilo termina su actualización.
HashMap no está sincronizado, por lo que es más rápido, pero puede tener problemas en un entorno de múltiples hilos.
Mire ConcurrentHashMap s para mapas Thread safe.
ofrecen todas las características de HashTable con una actuación muy cerca de un HashMap.
El rendimiento se obtiene si en lugar de utilizar un bloqueo de mapa amplio, la colección mantiene una lista de 16 bloqueos de forma predeterminada, cada uno de los cuales se utiliza para bloquear un solo depósito del mapa. Incluso puede configurar el número de cubos :) Ajustar esto puede ayudar al rendimiento en función de sus datos.
no puedo recomendar lo suficiente Java concurrencia en la práctica por Brian Goetz http://jcip.net/
sigo aprendiendo algo nuevo cada vez que lo leo.
Sí, todos los métodos se realizan atómicamente, pero el método values () no (consulte docs).
Paul fue más rápido que yo, recomendándote el paquete java.util.concurrent, que te proporciona un control muy preciso y estructuras de datos para entornos de multitrama.
Hashtables se sincronizan pero son una vieja aplicación que casi se podría decir está en desuso. Además, no permiten claves nulas (¿quizás tampoco valores nulos? No estoy seguro).
Un problema es que aunque todas las llamadas a métodos están sincronizadas, la mayoría de las acciones interesantes requieren más de una llamada, por lo que debe sincronizar las diferentes llamadas.
Un nivel similar de sincronización puede ser obtenida para HashMaps llamando:
Map m = Collections.synchronizedMap(new HashMap());
que envuelve un mapa en llamadas a métodos sincronizados. Pero esto tiene los mismos inconvenientes de concurrencia que Hashtable.
Como dice Pablo, ConcurrentHashMaps proporcionar mapas de seguridad de rosca con métodos útiles adicionales para actualizaciones atómicas.
Las tablas hash todavía no están en desuso (no estoy seguro de por qué), pero la interfaz del diccionario que implementan se considera obsoleta. – Powerlord
También tenga en cuenta que Hashtable y Collections.synchronizedMap son seguros solo para operaciones individuales. Cualquier operación que involucre varias teclas o verificar-luego-actuar que necesite ser atómica será no y será necesario un bloqueo adicional del lado del cliente.
Por ejemplo, no se puede escribir cualquiera de los siguientes métodos sin bloqueo adicional:
intercambio de los valores en dos claves diferentes: swapValues(Map, Object k1, Object k2)
anexar el parámetro de valor en una clave: appendToValue(Map, Object k1, String suffix)
Y sí, todo esto se trata en JCIP :-)
'ConcurrentMap' agrega algunos métodos muy útiles a' Map'. –
El problema surgirá solo si tenemos variables de instancia correctas? Con las variables que se declaran y usan dentro de la firma del método, no habrá problemas en el entorno multiproceso. Por favor, corrige si está mal. –
Pueden surgir problemas * más rápido * con variables de instancia, pero ese no es el problema. El problema es compartir variables sin ningún tipo de * control *. Utilizo un ConcurrentHashMap estático sin problemas (estoy absolutamente de acuerdo con la respuesta de Paul) :) – ATorras
¿Cómo compartirá la variable que no es de instancia ??????? –