The operation of the ArrayList can be accessed by means of an index image, or accessed through iterator, as long as no modification to the ArrayList structure will cause concurrentmodificationexception, modifying ArrayList with an index alone does not cause the problem, causing the problem to be mixed with indexes and iterator. You can use the source code of the JDK to illustrate the problem.
First look at the code inside the Abstractlist iterator:
Java code
- /**
- * There is a expectedmodcount variable inside the iterator,
- * Each time the variable initializes *iterator equals ArrayList Modcount,modcount records the number of structural modifications to the ArrayList,
- * The Expectedmodcount and Modcount are synchronized when the structure of the ArrayList is modified by iterator.
- * But if the structure of ArrayList is modified by means of an index while accessing through iterator,
- * Due to the way the index is only modified modcount will not be modified synchronously expectedmodcount will cause
- *modcount and Expectedmodcount are not equal, they throw concurrentmodificationexception,
- * This is the fail-fast of iterator, fast failure. So as long as a way to operate ArrayList will not be a problem,
- * Of course ArrayList is not thread-safe and is not discussed here for threading issues.
- *
- */
- int expectedmodcount = Modcount;
- Public E Next () {
- Checkforcomodification (); //Determine if Modecount and expectedmodcount are equal and throw exceptions if they are not equal
- try {
- E next = get (cursor);
- Lastret = cursor++;
- return next;
- } catch (Indexoutofboundsexception e) {
- Checkforcomodification ();
- throw new Nosuchelementexception ();
- }
- }
- Public void Remove () {
- if (Lastret = =-1)
- throw new IllegalStateException ();
- Checkforcomodification (); //To determine whether Modecount and Expectedmodcount are equal
- try {
- Abstractlist. This.remove (Lastret);
- if (Lastret < cursor)
- cursor--;
- Lastret =-1;
- Expectedmodcount = Modcount; //Here to modify the structure of the ArrayList, so the Expectedmodcount in Modcount synchronization, mainly AbstractList.this.remove (Lastret); The Remove method will be modcount++, resulting in modcount and expectedmodcount are not equal.
- } catch (Indexoutofboundsexception e) {
- throw new Concurrentmodificationexception ();
- }
- }
- Determine if Modcount and expectedmodcount are equal, and if not equal, throw concurrentmodificationexception anomalies
- Final void Checkforcomodification () {
- if (modcount! = expectedmodcount)
- throw new Concurrentmodificationexception ();
- }
Therefore, the conclusion is: the operation of the ArrayList is a traversal, either indexed, or iterator do not mix.
Here is an explanation of what others have seen online: wrote
Iterator is working in a separate thread, and has a mutex lock. Iterator is created after the creation of a single-chain index table pointing to the original object, when the original object number changes, the contents of the index table will not be synchronized changes, so when the index pointer moves back to find the object to iterate, so according to Fail-fast principle Iterator The java.util.ConcurrentModificationException exception is thrown immediately.
So Iterator is not allowed to be changed by iterative objects while working. But you can delete the object using Iterator's own method remove (), and the Iterator.remove () method maintains the consistency of the index while deleting the current iteration object
About the concurrentmodificationexception of list