Page History

            According to the Java API documentation \[[API 2006|AA. Bibliography#APIReferences#API 06]\] for the {{Iterator.remove()}} method:

According to the Java API documentation \[[API 2006|AA. Bibliography#APIReferences#API 06]\] for {{ConcurrentModificationException}}:

Reliance on {{ConcurrentModificationException}} is inadequate to prevent undefined behavior resulting from modifying an underlying collection while simultaneously iterating over the collection. The fail-fast behavior may occur only after processing an arbitrary number of elements. In _Java Concurrency in Practice_ \[[Goetz 2006|AA. Bibliography#GoetzReferences#Goetz 06]\], Goetz and colleagues note:

This approach must be implemented correctly to avoid starvation, deadlock, and scalability issues \[[Goetz 2006|AA. Bibliography#GoetzReferences#Goetz 06]\]. 

Creating deep copies of the list prevents underlying changes in the original list from affecting the iteration in progress. "Since the clone is thread-confined, no other thread can modify it during iteration, eliminating the possibility of {{ConcurrentModificationException}}. (The collection still must be locked during the clone operation itself)" \[[Goetz 2006a|AA. Bibliography#GoetzReferences#Goetz 06]\]. However, this approach is often more expensive than other techniques. There is also a risk of operating on stale data, which may affect the correctness of the code.