ConcurrentModificationException when processing HashMap

I'm trying to put a HashMap<Object, List<Object>> into my dataModel, but when i call the template.process() method, I get the following exception:

java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
    at java.util.HashMap$KeyIterator.next(HashMap.java:828)
    at freemarker.template.SimpleCollection$SimpleTemplateModelIterator.next(SimpleCollection.java:142)
    at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:157)
    at freemarker.core.Environment.visit(Environment.java:351)
    at freemarker.core.IteratorBlock.accept(IteratorBlock.java:95)
    at freemarker.core.Environment.visit(Environment.java:196)
    at freemarker.core.MixedContent.accept(MixedContent.java:9开发者_C百科2)
    at freemarker.core.Environment.visit(Environment.java:196)
    at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:172)
    at freemarker.core.Environment.visit(Environment.java:351)
    at freemarker.core.IteratorBlock.accept(IteratorBlock.java:95)
    at freemarker.core.Environment.visit(Environment.java:196)
    at freemarker.core.MixedContent.accept(MixedContent.java:92)
    at freemarker.core.Environment.visit(Environment.java:196)
    at freemarker.core.Environment.process(Environment.java:176)
    at freemarker.template.Template.process(Template.java:232)

After looking over some articles and older questions, I've tried to use a ConcurrentHashMap instead, to the same result. I've also tried making a copy using new HashMap<Object, List<Object>>(oldHashMap). Are there any other common fixes to this problem I could try?

EDIT: I know the general cause of ConcurrentModificationExceptions. Please only reply if you can help me understand why the framework Freemarker is throwing these exceptions, mkay? =)

Thanks!

The ConcurrentModificationException is caused by using an invalid iterator after the underlying collection has been changed. The only way to fix this is not changing the collection you are iterating over. In most cases this is not caused by multi-threading.

Simple Example:

//throws an exception in the second iteration
for(String s: list){
   list.remove(s);//changes the collection
}

fix 1, not supported by all iterators:

Iterator<String> iter = list.iterator();
while(iter.hasNext()){
    iter.next();
    iter.remove();//iterator still valid
} 

fix 2:

List<String> toRemove = ...;
for(String s: list){
   toRemove.add(s);
}
list.removeAll(toRemove);

The exception means that, while you're iterating over the map, something has changed the map's contents.

Your best course of action is figure out what that "something" is. For example, it could be another thread, or it could be that you have a foreach loop and modify the map from within the loop.

It is very hard to give advice on how to best fix the problem until we understand what exactly is causing it and what the desired behaviour is.

You'll get this kind of problem on List and Map when doing something like this:

List<A> list = ...; //a list with few elements
for(A anObject : list){
  list.add(anotherObject); //modify list inside the loop
}

The same goes with maps. The solution is to look for possible places where you might be modifying the map inside the loop over that map. Or if you are using a multi-threaded application, then it's possible that another thread is looping over the map while you are modifying it (or visa-versa). In such case you'll need to synchronize access to the map in both places: looping code and map modifying code.

There some info on it in the Java API for TreeMap here.

The iterators returned by the iterator method of the collections returned by all of this class's "collection view methods" are fail-fast: if the map is structurally modified at any time after the iterator is created, in any way except through the iterator's own remove method, the iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.

Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.

Synchronise access to the hashmap so that only one thread can be accessing the hashmap at once.