List throws ConcurrentModificationException but set does not throws ConcurrentModificationException? [duplicate]

Answer 1

This is a kind of 'retrograde' behavior, insomuch as iterators, once fully traversed, are not reusable, aka their hasNext method should return false when you reach the end of the list.

In this case though, the iterator returned by ArrayList.iterator is an internal implementation class, with code for hasNext as follows:

public boolean hasNext() {
    return cursor != size;
}

So when you call hasNext in your second loop, it indicates (falsely) that there are more items to iterate over, because you executed an operation that changed the size of the list, after the first iteration. Semantically, you should not be able to continue iterating over items in the list after you reach the end of it, but due to this implementation detail it lets you proceed with the second while loop. Of course, at that point, you get a concurrent modification exception because of the change you made in the backing list.

On the other hand, the iterator used by your hash set has its hasNext implemented as follows:

public final boolean hasNext() {
    return next != null;
}

This implementation happens not to be as 'vulnerable' to modifications made to the hash set after an iteration has been completed, and as such the hasNext method is better behaved.

Answer 2

 public static void main(String[] ar) {
            List<String> list = new ArrayList<String>();
            list.add("core java");
            list.add("php");
            list.add("j2ee");
            list.add("struts");
            list.add("hibernate");

            Iterator<String> itr = list.iterator();

            while (itr.hasNext()) {
                System.out.println(itr.next());
            }
            list.remove("php");

          /*  while (itr.hasNext()) {
                System.out.println(itr.next());
            }*/

        }

problem in itr object.it holds the list object reference

Answer 3

Hashset can throw a ConcurrentModificationException if you do anything to the set except through the iterator. However, there are a lot of heuristics around the itertor's fast-fail behavior with the goal to complete the iteration if at all possible. The JavaDocs seem pretty clear on it's behavior.

Answer 4

In case of list when we traverse it with first loop Iterator itr = set.iterator();

    while (itr.hasNext()) {
        System.out.println(itr.next());
    }

The cursor value and size will become same.Cursor contains value for total no of elements traversed and inside hashNext() method for list traversal contains code as:

  public boolean hasNext() {
            return cursor != size;
        }

So after first while loop cursor == size.But after removing element from list size becomes (originalSize-1).So for next while loop it goes inside while and inside itr.next() method it checks for modcount modification and throws ConcurrentModificationException.

In case of Set it checks for next != null for every itr.hasnext() call.And after traversing first while loop next becomes null.Removing element from set does not affect next value as null and itr.hasNext will return next == null as true and hence it does not go inside while loop to check modcount modification.And hence it does not throw ConcurrentModification Exception.

Answer 5

Start by reading the JavaDoc for Iterator. Does it mention ConcurrentModificationException anywhere?

Now, read the JavaDoc for ConcurrentModificationException, and note the following (emphasis added):

This exception may be thrown by methods that have detected concurrent modification of an object when such modification is not permissible.

Now look closely at your code. Your while loop iterates through all elements of the collection (even though the output of your first example doesn't indicate this, which tells me that either you've edited the output or this is not your actual code). At the time you remove the element, there are no more items to iterate, so the second loop should always exit immediately.

So, the conclusion is that the implementers of the list iterator have chosen that to throw that exception even when there are no more elements to iterate, while the implementers of the set iterator have chosen not to. Both cases are completely acceptable given the specifications.

Answer 6

This is a difference in the implementation: the iterator returned by the array list detects concurrent modifications even when it is positioned at the end, because it checks the length; iterators of the HashSet, TreeSet and LinkedList, on the other hand, do not detect this condition, because they check for being positioned at the end before checking for concurrent modification. The documentation allows iterators not to throw on concurrent modifications, so both approaches are valid.

• Demo for the TreeSet.
• Demo for the LinkedList.