According to the Java API documentation [API 20062014] for the Iterator.remove()
method:
...
According to the Java API documentation [API 20062014] for ConcurrentModificationException
:
It is not generally permissible for one thread to modify a
Collection
while another thread is iterating over it. In general, the results of the iteration are undefined under these circumstances. SomeIterator
implementations (including those of all the general purpose collection implementations provided by the JRE) may choose to throw this exception if this behavior is detected.Iterators
that do this are known as fail-fast iterators, as they fail quickly and cleanly, rather that risking arbitrary, non-deterministic behavior at an undetermined time in the future....
Note that fail-fast behavior cannot be guaranteed because 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. ConsequentlyTherefore, it would be wrong to write a program that depended on this exception for its correctness:ConcurrentModificationException
should be used only to detect bugs.
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 2006a], Goetz and colleagues note:
...
This approach must be implemented correctly to avoid starvation, deadlock, and scalability issues [Goetz 2006a].
...
This compliant solution creates a deep copy of the mutable widgetList
before iterating over it.:
Code Block | ||
---|---|---|
| ||
List<Widget> widgetList = new ArrayList<Widget>(); public void widgetOperation() { List<Widget> deepCopy = new ArrayList<Widget>(); synchronized (widgetList) { // Client-side locking for (Object obj : widgetList) { deepCopy.add(obj.clone()); } } for (Widget w : deepCopy) { doSomething(w); } } |
...
The CopyOnWriteArrayList
data structure implements all mutating operations by making a fresh copy of the underlying array. It is fully thread-safe and is optimized for cases where in which traversal operations vastly outnumber mutations. Note that traversals of such lists always see the list in the state it had at the creation of the iterator (or enhanced for
loop); subsequent modifications of the list are invisible to an ongoing traversal. Consequently, this solution is inappropriate when mutations of the list are frequent or when new values should be reflected in ongoing traversals.
...
Risk Assessment
Modifying a Collection
while iterating over it results in undefined behavior.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MSC06-J | Low | Probable | Medium | P4 | L3 |
Automated Detection
Some static analysis tools can detect cases where an iterator is being used after the source container of the iterator is modified.
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.MSC06.ITMOD | Do not modify collection while iterating over it | ||||||
PVS-Studio |
| V6053 |
Related Vulnerabilities
The Apache Harmony bug HARMONY-6236 documents an ArrayList
breaking when given concurrent collections as input.
Bibliography
[API |
2014] |
[SDN 2008]
Section 5.1.2 |
, "Iterators and |
...
...