Quelle est la différence entre eux ...
«Fail-safe» ( en ingénierie ) signifie que quelque chose échoue d'une manière qui ne cause aucun dommage ou un dommage minimal. À proprement parler, il n'existe pas en Java d'itérateur à sécurité intégrée. Si un itérateur échoue (dans le sens normal de «échec»), vous pouvez vous attendre à ce que des dommages se produisent.
Je soupçonne que vous entendez en fait des itérateurs "faiblement cohérents". Le javadoc dit:
"La plupart des implémentations de collection simultanées (y compris la plupart des files d'attente) diffèrent également des conventions java.util habituelles en ce que leurs itérateurs et séparateurs fournissent une traversée faiblement cohérente plutôt que rapide."
En règle générale, une cohérence faible signifie que si une collection est modifiée en même temps qu'une itération, les garanties de ce que voit l'itération sont plus faibles. (Les détails seront spécifiés dans chaque javadocs de classes de collection simultanées.)
«Fail-fast» ( dans la conception des systèmes ) signifie que la condition de défaillance est vérifiée de manière agressive afin que la condition de défaillance soit (si possible 1 ) détectée avant que trop de dommages ne puissent être causés. En Java, un itérateur rapide échoue en lançant un fichier ConcurrentModificationException.
L'alternative à "fail-fast" et "faiblement cohérent" est sémantique là où l'itération échoue de manière imprévisible; par exemple pour donner parfois la mauvaise réponse ou lancer une exception inattendue. (C'était le comportement de certaines implémentations standard de l' EnumerationAPI dans les premières versions de Java.)
... et sont-ils différents de l'itérateur que nous utilisons pour la collecte.
Non. Ce sont les propriétés des itérateurs implémentés par les types Collection standard; c'est-à-dire qu'ils sont soit "échouent rapidement" soit "faiblement cohérents" ... lorsqu'ils sont utilisés correctement par rapport à la synchronisation et au modèle de mémoire Java 1 .
Les itérateurs à échec rapide sont généralement implémentés à l'aide d'un volatilecompteur sur l'objet de collection.
- Lorsque la collection est mise à jour, le compteur est incrémenté.
- Lors de la création d'un
Iterator, la valeur actuelle du compteur est incorporée dans l' Iteratorobjet.
- Lorsqu'une
Iteratoropération est effectuée, la méthode compare les deux valeurs de compteur et lance un CME si elles sont différentes.
En revanche, les itérateurs faiblement cohérents sont généralement légers et tirent parti des propriétés des structures de données internes de chaque collection simultanée. Il n'y a pas de modèle général. Si vous êtes intéressé, lisez le code source des différentes classes de collection.
1 - Le cavalier est que le comportement Fail-Fast suppose que l'application identifie correctement par rapport à la synchronisation et au modèle de mémoire. Cela signifie que (par exemple) si vous effectuez une itération ArrayListsans synchronisation appropriée, le résultat peut être un résultat de liste corrompu. Le mécanisme "d'échec rapide" détectera probablement la modification simultanée (bien que ce ne soit pas garanti), mais il ne détectera pas la corruption sous-jacente. À titre d'exemple, javadoc for Vector.iterator()dit ceci:
"Le comportement de défaillance rapide d'un itérateur ne peut pas être garanti car il est, d'une manière générale, impossible de faire des garanties concrètes en présence de modifications concurrentes non synchronisées. Les itérateurs rapides de défaillance lancent ConcurrentModificationExceptionsur la base du meilleur effort. Par conséquent, ce serait incorrect d'écrire un programme qui dépendait de cette exception pour son exactitude: le comportement rapide des itérateurs ne devrait être utilisé que pour détecter les bogues. "