Wiki Markup |
---|
The {{java.util.Collections}} interface's documentation \[[API 2006|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. |
...
A class that uses a collection view instead of the backing collection as the lock 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.
Noncompliant Code Example (Collection View)
...
{quote} A class that uses a collection view instead of the backing collection as the lock 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 {{HashMap}} encapsulated by the {{map}} field and a set view of the map's keys encapsulated by the {{set}} field. This example synchronizes on the {{set}} view \[[Tutorials 2008|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} In this example, {{HashMap}} provides the backing collection for {{Map}}, which provides the backing collection for {{Set}}, as shown in the following figure: |
...
HashMap
is not accessible, but the Map
view is. Because the Set
view is synchronized instead of Map
view, another thread can modify the contents of map
and invalidate the k
iterator.
Compliant Solution (Collection Lock Object)
This compliant solution synchronizes on the map
view instead of the set
view.
Code Block | ||
---|---|---|
| ||
!con06-j-backing-collection.JPG! {{HashMap}} is not accessible, but the {{Map}} view is. Because the {{Set}} view is synchronized instead of {{Map}} view, another thread can modify the contents of {{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 code 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 can cause nondeterministic behavior. |
...
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
LCK04-J | low | probable | medium | P8 | L2 |
References
...
|| Guideline || Severity || Likelihood || Remediation Cost || Priority || Level || | LCK04-J | low | probable | medium | {color:#cc9900}{*}P8{*}{color} | {color:#cc9900}{*}L2{*}{color} | h2. References \[[API 2006|AA. Java References#API 06]\] Class Collections \[[Tutorials 2008|AA. Java References#Tutorials 08]\] [Wrapper Implementations|http://java.sun.com/docs/books/tutorial/collections/implementations/wrapper.html] |
...
----
[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|LCK03-J. Do not synchronize on the intrinsic locks of high-level concurrency objects] [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|12. Locking (LCK)] [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|LCK05-J. Synchronize access to static fields that may be modified by untrusted code] |