Home > Uncategorized > java.util.ConcurrentModificationException


java.util.ConcurrentModificationException… it always worries me when I come across an error that I do not understand, and which is completely unexpected.

You’d expect a concurrent error exception to only occur when you are using threading, or have multiple applications accessing the same resource(s). However, this was not the case this morning.

I had a simple, single-threaded logic, running through a list of URLs and removing some instances based on regex pattens. Standard, plain-vanilla Java operations.

The error that occurred took place at this line of code:

String nextCheckSum = i_safeDivs.next().toString();

i_safeDivs is an iterator over the a java HashMap (SafeDivs) data structure. This one was a PITA to figure out, as the error was occurring during a call to the ‘next()’ operator, while it was actually due an element being deleted a few lines down !

Apparently, this exception can occur anytime when you are working with maps and other Collection utilities in Java:

The API documentation of ConcurrentModificationException says:

“This exception may be thrown by methods that have detected concurrent modification of an object when such modification is not permissible. For example, it is not generally permissible for one thread to modify a Collection while another thread is iterating over it…”

The problem (and solution) has very little to do with Concurrent Access. Actually, the issue is that when you remove elements from a Map (or other Collection DS) on which you have a live Iterator, you need to remove it via the Iteration’s iterator.remove() method rather than by directly accessing the HashMaps hashMap.remove(key) method.

If you have an Iterator open, when you remove the key from KeySet the iterator logic breaks, throwing the ConcurrentModificationException. To avoid this use the same Iterator (keySetItr) for both for iteration and to remove the keys.

  1. fazel
    October 14th, 2009 at 15:57 | #1

    hello Shahzad,

    I had the same problem while ago!!
    When I used to pass my HT to a method to do something(in that method I needed to remove elements from my hashtable). BUT, after my jobs finished in that method… I saw surprisingly I have no more my HT!!!
    You did your trick!! But I got another solution:
    Instead of passing the whole HT to method, I passed the ‘clone’ of HT to method,lol.
    It’s Java way!! Java won’t keep the original Map or HT when you removing their objects, so to keep the original, must pass the “clone” instead…


  2. October 14th, 2009 at 20:04 | #2

    Hi Fazel,
    You’re right about this. The way that java actually handles the passing of parameters in methods is something that a lot of people are confused by.

    Java has much in common with C++, but the lack of pointers can complicate things. You don’t actually lose any of the power of pointers though.

    It’s an important topic, and I’ll write up a quick blog post to describe this. Thanks for bringing this up.

  1. October 14th, 2009 at 20:16 | #1