The Java Tutorials, Wrapper Implementations [Java Tutorials], warns about the consequences of failing to synchronize on an accessible collection object when iterating over its view:
It is imperative that the user manually synchronize on the returned
Map
when iterating over any of itsCollection
views rather than synchronizing on theCollection
view itself.
Disregarding this advice may result in nondeterministic behavior.
Any class that uses a collection view rather than the backing collection as the lock object may end up with two distinct locking strategies. When the backing collection is accessible to multiple threads, the class that locked on the collection view has violated the thread-safety properties and is unsafe. Consequently, programs that both require synchronization while iterating over collection views and have accessible backing collections must synchronize on the backing collection; synchronization on the view is a violation of this rule.
Noncompliant Code Example (Collection View)
This noncompliant code example creates a HashMap
object and two view objects: a synchronized view of an empty HashMap
encapsulated by the mapView
field and a set view of the map's keys encapsulated by the setView
field. This example synchronizes on setView
[Java Tutorials].
Code Block | ||
---|---|---|
| ||
private final Map<Integer, String> mapView =
| ||
Wiki Markup | ||
The {{java.util.Collections}} interface's documentation \[[API 06|AA. Java References#API 06]\] warns about the consequences of synchronizing on any view over a collection object, rather than synchronizing on the collection object itself. {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} Synchronize on the original Collection object when using synchronization wrappers to enforce atomicity ([CON07-J. Do not assume that a group of calls to independently atomic methods is atomic]). {mc} This also applies to {{java.util.Map}} objects, even though Maps are technically not Collections. -- Good point but I think you mean the Collections interface. Acc to interface map API: "This interface is a member of the Java Collections Framework". Moreover it has collection views as stated in the API ref. -- No, I mean the Collection interface. Collections is a class with several static methods. Maps are part of the Collection framework even though they don't implement {{Collection}}. Hence I removed bracees ~DS {mc} h2. Noncompliant Code Example (collection view) This noncompliant code example incorrectly synchronizes on the {{set}} view of the synchronized map ({{map}}) instead of the collection object \[[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> setsetView = mapmapView.keySet(); public Map<Integer, String> getMap() { return mapView; } public void doSomething() { synchronized (setsetView) { // Incorrectly synchronizes on setsetView for (Integer k : setsetView) { // ... } } } {code} h2. Compliant Solution (collection lock object) This compliant solution synchronizes on the original {{Collection}} object {{map}} instead of the {{Collection}} view {{set}}. {code:bgColor=#ccccff} // map has package-private accessibility |
In this example, HashMap
provides the backing collection for the synchronized map represented by mapView
, which provides the backing collection for setView
, as shown in the following figure.
The HashMap
object is inaccessible, but mapView
is accessible via the public getMap()
method. Because the synchronized
statement uses the intrinsic lock of setView
rather than of mapView
, another thread can modify the synchronized map and invalidate the k
iterator.
Compliant Solution (Collection Lock Object)
This compliant solution synchronizes on the mapView
field rather than on the setView
field:
Code Block | ||
---|---|---|
| ||
private final Map<Integer, String> mapmapView = Collections.synchronizedMap(new HashMap<Integer, String>()); private final Set<Integer> setsetView = mapmapView.keySet(); public Map<Integer, String> getMap() { return mapView; } public void doSomething() { synchronized (mapmapView) { // Synchronize on map, notrather than set for (Integer k : setsetView) { // ... } } } {code} 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/ |
This code is compliant because the map's underlying structure cannot be changed during the iteration.
Risk Assessment
Synchronizing on a collection view instead of the collection object can cause nondeterministic behavior.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
LCK04-J | Low | Probable | Medium | P4 | L3 |
Automated Detection
Some static analysis tools are capable of detecting violations of this rule.
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.LCK04.SOBC | Do not synchronize on a collection view if the backing collection is accessible | ||||||
ThreadSafe |
| CCE_CC_SYNC_ON_VIEW | Implemented |
Bibliography
Issue Tracking
Tasklist | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
implementations/wrapper.html] h2. Issue Tracking {tasklist:Review List} ||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name|| |F|M|F|12694530746511270825291208| |dmohindr|"warnssuggested about=> the"HashMap consequencesis of synchronizing on any view over a collection object, rather than synchronizing on the collection object" ... it doesn't warn against it...it just says you should synchronize the collection...suggest reverting the change| |T|M|F|1269452979738|1269635061216|rcs|The title could do away with "still"| {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] not accessible, but the Map view is. Because the set view is synchronized instead of the map view, another thread can modify the contents of map and invalidate the k iterator."| |
...