According to the Java API documentation [[API 06]] for Iterator.remove()
method:
The behavior of an iterator is unspecified if the underlying collection is modified while the iteration is in progress in any way other than by calling this method.
It is possible that in a multithreaded program, one thread iterates over a collection while another concurrently modifies it. This can result in unspecified behavior. Many implementations throw a ConcurrentModificationException
when such a condition is detected.
According to the Java API documentation [[API 06]] 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 as 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. Consequently, it would be wrong to write a program that depended on this exception for its correctness:ConcurrentModificationException
should be used only to detect bugs.
The message is clear, do not rely on ConcurrentModificationException
to stop any side effects resulting from modifying an underlying Collection while iterating over it. Notably, the enhanced for
loop (for-each idiom) internally uses an Iterator
.
Noncompliant Code Example
This noncompliant code example (based on a bug report 6687277) removes an element from an ArrayList
using the Collection's remove()
method. This is done while iterating over the Collection
. The resulting behavior is unspecified.
class BadIterate { public static void main(String[] args) { List<String> list = new ArrayList<String>(); list.add("one"); list.add("two"); Iterator iter = list.iterator(); while(iter.hasNext()) { String s = (String)iter.next(); if(s.equals("one")) list.remove(s); } } }
Compliant Solution
The Iterator.remove()
method removes from the underlying Collection
the last element returned by the iterator. Its behavior is fully specified.
// ... iter.remove(); // ...
Exceptions
EX1: The Iterator.remove()
method can be used to modify the underlying collection when an iteration is in progress. This is also shown in the compliant solution.
Risk Assessment
Modifying a Collection while iterating over it can lead to nondeterministic behavior.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
MSC33- J |
low |
probable |
medium |
P4 |
L3 |
Automated Detection
TODO
Related Vulnerabilities
References
[[API 06]] Class ConcurrentModificationException
[[SDN 08]] Sun Bug database, Bug ID:6687277
[[Goetz 06]] 5.1.2. Iterators and Concurrentmodificationexception
MSC32-J. Make sensitive classes noncloneable 49. Miscellaneous (MSC) VOID MSC34-J. Do not base critical decisions on IP addresses or DNS lookups