Such as container Map in Java:
for(Person person : pList){
if(person.getGender()==Gender.MALE){
pList.remove(person); //The remove operation cannot be performed during traversal
}
}
When traversing a Map, it usually obtains the Set of its key values, and then uses an iterator to traverse the Map.
Note that during the traversal process, only the elements in the Map can be processed accordingly. Map elements cannot be added or reduced. In other words, the size of the Map cannot be changed, and an exception will occur (cannot be used during the traversal process). modify, delete or add elements in the map)
The exception reported is java.util.ConcurrentModificationException exception
public class ConcurrentModificationExceptionextends RuntimeException
This exception is thrown when a method detects concurrent modification of an object, but does not allow such modification.
For example, while one thread is iterating over a Collection, another thread is typically not allowed to linearly modify the Collection. Often in these cases, the results of the iteration are unclear. Some iterator implementations (including all generic collection implementations provided by the JRE) may choose to throw this exception if this behavior is detected. Iterators that perform this operation are called fail-fast iterators because the iterator fails completely quickly without risking arbitrary unspecified behavior at some time in the future.
Note that this exception will not always indicate that the object has been modified concurrently by different threads. An object may throw this exception if a single thread issues a sequence of method calls that violates the object's contract. For example, if a thread directly modifies a collection while iterating over it using a fail-fast iterator, the iterator will throw this exception.
Note that the fail-fast behavior of iterators is not guaranteed because, in general, it is not possible to make any hard guarantees about whether unsynchronized concurrent modifications will occur. Fail-fast operations throw a ConcurrentModificationException on a best-effort basis. Therefore, it is a mistake to write a program that relies on this exception to improve the correctness of such operations. The correct approach is: ConcurrentModificationException should only be used to detect bugs.
When trying to directly modify the contents of a Collection/Map while using a fail-fast iterator to iterate over a Collection or Map, a java.util.ConcurrentModificationException exception will be thrown even when running under a single thread.
Iterator works in a separate thread and has a mutex lock. After the Iterator is created, a single-linked index table pointing to the original object will be established. When the number of original objects changes, the contents of this index table will not change synchronously, so when the index pointer moves backward, it cannot be found to iterate. object, so according to the fail-fast principle Iterator will immediately throw a java.util.ConcurrentModificationException exception.
Therefore, the Iterator does not allow the iterated object to be changed while it is working. But you can use Iterator's own method remove() to delete objects. The Iterator.remove() method will delete the current iteration object while maintaining the consistency of the index.
What's interesting is that if your Collection / Map object actually has only one element, the ConcurrentModificationException exception will not be thrown. This is why it is pointed out in the javadoc: it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.