The {{java.util.Collections}} interface's documentation \[[API 06|AA. Java References#API 06]\] warns about the consequences of failing to synchronize on an accessible collection object when iterating over its view:
{quote}
It is imperative that the user manually synchronize on the returned map when iterating over any of its collection views... Failure to follow this advice may result in non-deterministic behavior.
{quote}
If theA class that uses a collection view is synchronized instead of the backing collection, as the classlock object, may end up with two different locking strategies. In this case, if the backing collection is accessible to multiple threads, the class is not thread-safe.
{mc} I don't see the point of this statement
To make a group of statements atomic, synchronize on the original collection object when using synchronization wrappers.([CON07-J. Do not assume that a group of calls to independently atomic methods is atomic]).
{mc}
h2. Noncompliant Code Example (collection view)
This noncompliant code example creates two views, a synchronized view of an empty map encapsulated by the {{map}} field, and a set view of the map's keys encapsulated by the {{set}} field. Furthermore, this code synchronizes on the {{set}} view instead of the more accessible {{map}} view \[[Tutorials 08|AA. Java References#Tutorials 08]\].
{code:bgColor=#FFcccc}
// map has package-private accessibility
final Map<Integer, String> map = Collections.synchronizedMap(new HashMap<Integer, String>());
private final Set<Integer> set = map.keySet();
public void doSomething() {
synchronized(set) { // Incorrectly synchronizes on set
for (Integer k : set) {
// ...
}
}
}
{code}
If the set is synchronized instead of the map, another thread may modify the contents of the map, and invalidate the {{k}} iterator.
h2. Compliant Solution (collection lock object)
This compliant solution synchronizes on the {{map}} view instead of the {{set}} view.
{code:bgColor=#ccccff}
// map has package-private accessibility
final Map<Integer, String> map = Collections.synchronizedMap(new HashMap<Integer, String>());
private final Set<Integer> set = map.keySet();
public void doSomething() {
synchronized(map) { // Synchronize on map, not set
for (Integer k : set) {
// ...
}
}
}
{code}
This is compliant because the map's underlying structure cannot be changed when an iteration is in progress.
h2. Risk Assessment
Synchronizing on a collection view instead of the collection object may cause non-deterministic behavior.
|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| CON40-J | medium | probable | medium | {color:#cc9900}{*}P8{*}{color} | {color:#cc9900}{*}L2{*}{color} |
h3. Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+CON36-J].
h2. References
\[[API 06|AA. Java References#API 06]\] Class Collections
\[[Tutorials 08|AA. Java References#Tutorials 08]\] [Wrapper Implementations|http://java.sun.com/docs/books/tutorial/collections/implementations/wrapper.html]
h2. Issue Tracking
{tasklist:Review List}
||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name||
{tasklist}
----
[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|VOID CON00-J. Synchronize access to shared mutable variables] [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|11. Concurrency (CON)] [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|CON03-J. Do not use background threads during class initialization]
|