Tel que le conteneur Map en Java :
pour(Personne personne : pList){
if(person.getGender()==Gender.MALE){
pList.remove(person); //L'opération de suppression ne peut pas être effectuée pendant le parcours
}
}
Lors du parcours d'une carte, il obtient généralement l'ensemble de ses valeurs clés, puis utilise un itérateur pour parcourir la carte.
Notez que pendant le processus de parcours, seuls les éléments de la carte peuvent être traités en conséquence. Les éléments de la carte ne peuvent pas être ajoutés ou réduits. En d'autres termes, la taille de la carte ne peut pas être modifiée et une exception se produira (ne pourra pas être utilisée pendant le processus de parcours). processus de parcours), modifier, supprimer ou ajouter des éléments dans la carte)
L'exception signalée est l'exception java.util.ConcurrentModificationException
classe publique ConcurrentModificationExceptionextends RuntimeException
Cette exception est levée lorsqu'une méthode détecte une modification simultanée d'un objet, mais n'autorise pas une telle modification.
Par exemple, pendant qu'un thread parcourt une collection, un autre thread n'est généralement pas autorisé à modifier linéairement la collection. Souvent, dans ces cas, les résultats de l’itération ne sont pas clairs. Certaines implémentations d'itérateurs (y compris toutes les implémentations de collections génériques fournies par le JRE) peuvent choisir de lever cette exception si ce comportement est détecté. Les itérateurs qui effectuent cette opération sont appelés itérateurs à échec rapide, car l'itérateur échoue complètement rapidement sans risquer un comportement arbitraire non spécifié à un moment donné dans le futur.
Notez que cette exception n'indiquera pas toujours que l'objet a été modifié simultanément par différents threads. Un objet peut lever cette exception si un seul thread émet une séquence d'appels de méthode qui viole le contrat de l'objet. Par exemple, si un thread modifie directement une collection tout en la parcourant à l'aide d'un itérateur à échec rapide, l'itérateur lèvera cette exception.
Notez que le comportement rapide des itérateurs n'est pas garanti car, en général, il n'est pas possible de garantir de manière concrète si des modifications simultanées non synchronisées se produiront. Les opérations à échec rapide génèrent une ConcurrentModificationException au mieux. Par conséquent, c'est une erreur d'écrire un programme qui s'appuie sur cette exception pour améliorer l'exactitude de telles opérations. L'approche correcte est la suivante : ConcurrentModificationException ne doit être utilisée que pour détecter des bogues.
Lorsque vous essayez de modifier directement le contenu d'une collection/carte tout en utilisant un itérateur à échec rapide pour parcourir une collection ou une carte, une exception java.util.ConcurrentModificationException sera levée même lors de l'exécution sous un seul thread.
L'itérateur fonctionne dans un thread séparé et dispose d'un verrou mutex. Une fois l'itérateur créé, une table d'index à liaison unique pointant vers l'objet d'origine sera établie. Lorsque le nombre d'objets d'origine change, le contenu de cette table d'index ne changera pas de manière synchrone, donc lorsque le pointeur d'index recule, il ne peut pas. être trouvé pour itérer l'objet, donc selon le principe de l'échec rapide, Iterator lancera immédiatement une exception java.util.ConcurrentModificationException.
Par conséquent, l'itérateur ne permet pas de modifier l'objet itéré pendant son fonctionnement. Mais vous pouvez utiliser la propre méthode Remove() d'Iterator pour supprimer des objets. La méthode Iterator.remove() supprimera l'objet d'itération actuel tout en conservant la cohérence de l'index.
Ce qui est intéressant, c'est que si votre objet Collection/Map n'a en réalité qu'un seul élément, l'exception ConcurrentModificationException ne sera pas levée. C'est pourquoi cela est souligné dans la javadoc : ce serait une erreur d'écrire un programme dont l'exactitude dépendrait de cette exception : ConcurrentModificationException ne doit être utilisée que pour détecter des bugs.