¿Qué quiere decir exactamente con el iterador de HashMap que no es rápido y el enumerador de HashTable no lo es?

Question

que estaba buscando la diferencia entre las dos clases y este punto se planteó en muchas de las respuestas con este blog es la fuente: http://javarevisited.blogspot.com/2010/10/difference-between-hashmap-and.html

Sin embargo que no entiendo por completo. ¿Alguien puede elaborar esto? Tal vez con un ejemplo?

Gracias por mirar!

Answer 1

Fail-fast significa que cuando intenta modificar el contenido cuando está iterando a través de él, falla y lanza ConcurrentModificationException.

Set keys = hashMap.keySet(); 
for (Object key : keys) { 
    hashMap.put(someObject, someValue); //it will throw the ConcurrentModificationException here 
} 

para la enumeración HashTable:

Enumeration keys = hashTable.keys(); 
while (keys.hasMoreElements()) { 
      hashTable.put(someKey, someValue); //this is ok 
    } 

Answer 2

Al llamar iterator.next(), en su caso la modificación se ha hecho entre el momento en el repetidor se creó y el momento next() que se llama, un ConcurrentModificationException se lanza inmediatamente. Esto es lo que significa "fallar rápido".

Las enumeraciones devueltas por Hashtable no tienen este comportamiento. Suponen que usted sabe lo que está haciendo, y su comportamiento, AFAIK, no está definido si modifica el mapa mientras lo itera utilizando una de sus enumeraciones.

Answer 3

La mejor manera es probablemente mirar la fuente para cada clase implementada por la implementación Open JDK para cada clase; de esa manera, puede obtener su respuesta directamente de la boca del caballo, como si fuera :-)

Dejando eso de lado, esencialmente, "fail-fast" en este sentido significa que un Iterador sobre un HashMap lanzará una excepción si detecta que otro subproceso ha modificado el HashMap específico - si busca en el código fuente de HashMap, verá que esto se hace simplemente marcando un contador para la cantidad de modificaciones esperadas. Si el recuento de modificaciones es diferente de lo esperado por el iterador, eso significa que alguien más ha entrado desde el último control y ha manipulado el HashMap, por lo que el iterador lanza un ConcurrentModificationException.

Un iterador "no a prueba de fallas" no se molestaría en comprobarlo, y felizmente seguiría su negocio en la estructura de datos subyacente. Por lo tanto, obtienes cierta flexibilidad (probablemente dudosa flexibilidad en este caso) a cambio de posibles errores posteriores; es decir, intentar acceder a un valor que ya no está presente.

Como con todas las estrategias fail-fast, la idea es que cuanto más temprano se detecta un error, más fácil es recuperarlo o depurarlo.