This question already has answers here:
Closed 11 months ago.
I was reading about ConcurrentModificationException and how to avoid it. Found an article. The first listing in that article had code similar to the following, which would apparently cause the exception:
List<String> myList = new ArrayList<String>();
myList.add("January");
myList.add("February");
myList.add("March");
Iterator<String> it = myList.iterator();
while(it.hasNext())
{
String item = it.next();
if("February".equals(item))
{
myList.remove(item);
}
}
for (String item : myList)
{
System.out.println(item);
}
Then it went on to explain how to solve the problem with various suggestions.
When I tried to reproduce it, I didn't get the exception! Why am I not getting the exception?
According to the Java API docs Iterator.hasNext does not throw a ConcurrentModificationException
.
After checking "January"
and "February"
you remove one element from the list. Calling it.hasNext()
does not throw a ConcurrentModificationException
but returns false. Thus your code exits cleanly. The last String however is never checked. If you add "April"
to the list you get the Exception as expected.
import java.util.List;
import java.util.ArrayList;
import java.util.Iterator;
public class Main {
public static void main(String args[]) {
List<String> myList = new ArrayList<String>();
myList.add("January");
myList.add("February");
myList.add("March");
myList.add("April");
Iterator<String> it = myList.iterator();
while(it.hasNext())
{
String item = it.next();
System.out.println("Checking: " + item);
if("February".equals(item))
{
myList.remove(item);
}
}
for (String item : myList)
{
System.out.println(item);
}
}
}
http://ideone.com/VKhHWN
From ArrayList
source (JDK 1.7):
private class Itr implements Iterator<E> {
int cursor; // index of next element to return
int lastRet = -1; // index of last element returned; -1 if no such
int expectedModCount = modCount;
public boolean hasNext() {
return cursor != size;
}
@SuppressWarnings("unchecked")
public E next() {
checkForComodification();
int i = cursor;
if (i >= size)
throw new NoSuchElementException();
Object[] elementData = ArrayList.this.elementData;
if (i >= elementData.length)
throw new ConcurrentModificationException();
cursor = i + 1;
return (E) elementData[lastRet = i];
}
public void remove() {
if (lastRet < 0)
throw new IllegalStateException();
checkForComodification();
try {
ArrayList.this.remove(lastRet);
cursor = lastRet;
lastRet = -1;
expectedModCount = modCount;
} catch (IndexOutOfBoundsException ex) {
throw new ConcurrentModificationException();
}
}
final void checkForComodification() {
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
}
}
Every modifying operation on an ArrayList
increments the modCount
field (the number of times the list has been modified since creation).
When an iterator is created, it stores the current value of modCount
into expectedModCount
. The logic is:
- if the list isn't modified at all during the iteration,
modCount == expectedModCount
- if the list is modified by the iterator's own
remove()
method, modCount
is incremented, but expectedModCount
gets incremented as well, thus modCount == expectedModCount
still holds
- if some other method (or even some other iterator instance) modifies the list,
modCount
gets incremented, therefore modCount != expectedModCount
, which results in ConcurrentModificationException
However, as you can see from the source, the check isn't performed in hasNext()
method, only in next()
. The hasNext()
method also only compares the current index with the list size. When you removed the second-to-last element from the list ("February"
), this resulted that the following call of hasNext()
simply returned false
and terminated the iteration before the CME could have been thrown.
However, if you removed any element other than second-to-last, the exception would have been thrown.
I think the correct explanation is this extract from the javadocs of ConcurrentModificationExcetion:
Note that fail-fast behavior cannot be guaranteed as it is, generally
speaking, impossible to make any hard guarantees in the presence of
unsynchronized concurrent modification. Fail-fast operations throw
ConcurrentModificationException on a best-effort basis. Therefore, it
would be wrong to write a program that depended on this exception for
its correctness: ConcurrentModificationException should be used only
to detect bugs.
So, if the iterator is fail fast it may throw the exception but there´s no guarantee. Try replacing February
with January
in your example and the exception is thrown (At least in my environment)
The iterator checks that it has iterated as many times as you have elements left to see it has reached the end before it checks for a concurrent modification. This means if you remove only the second last element you don't see a CME in the same iterator.