1. Fail-Fast (fail—fast)

Lors de l'utilisation d'un itérateur pour parcourir un objet collection, si le contenu de l'objet collection est modifié (ajout, suppression ou modification) pendant le parcours, une Concurrent Modification Exception sera levée.

Principe :L'itérateur accède directement au contenu de la collection pendant le parcours et utilise une variable modCount durant le parcours. Si le contenu de la collection change pendant qu'elle est parcourue, la valeur de modCount sera modifiée. Chaque fois que l'itérateur utilise hashNext()/next() pour passer à l'élément suivant, il vérifie si la variable modCount est égale à la valeur expectedmodCount. Si oui, il poursuit le parcours ; sinon, il lève une exception et termine le parcours.

Remarque :La condition pour lever une exception ici est de détecter cette condition :modCount != expectedmodCount. Si la valeur de modCount est ramenée à la valeur expectedmodCount juste au moment où la collection change, l'exception ne sera pas levée. Par conséquent, vous ne pouvez pas vous fier au fait que cette exception soit levée lors de la programmation d'opérations concurrentes ; cette exception est uniquement recommandée pour détecter les bogues dans les modifications concurrentes.

Scénarios :Les classes de collection du package java.util sont toutes fail-fast et ne peuvent pas être modifiées de manière concurrente dans un environnement multithread (modifiées pendant l'itération).

2. Fail-Safe (fail—safe)

Les conteneurs de collection qui utilisent le mécanisme fail-safe n'accèdent pas directement au contenu de la collection pendant le parcours ; ils copient d'abord le contenu de la collection d'origine, puis parcourent la collection copiée.

Principe :Comme l'itération parcourt une copie de la collection d'origine, les modifications apportées à la collection d'origine pendant le parcours ne peuvent pas être détectées par l'itérateur, donc Concurrent Modification Exception ne sera pas déclenchée.