Page History

Wiki MarkupThe {{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 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 Map when iterating over any of its collection views... Failure to follow Collection views rather than synchronizing on the Collection view itself.

Disregarding this advice may result in

...

nondeterministic behavior.

A Any class that uses a collection view instead of rather than the backing collection as the lock object may end up with two different distinct locking strategies. In this case, if When the backing collection is accessible to multiple threads, the class is not thread-safethat 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 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]\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
bgColor #FFcccc
// map has package-private accessibility 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 (setsetView) { // Incorrectly synchronizes on setsetView for (Integer k : setsetView) { // ... } } }

In this example, HashMap provides the backing collection for Mapthe synchronized map represented by mapView, which provides the backing collection for Set setView, as shown in the following figure:.

The HashMap object is not accessibleinaccessible, but the Map view is mapView is accessible via the public getMap() method. Because the Set view is synchronized instead of Map view synchronized statement uses the intrinsic lock of setView rather than of mapView, another thread can modify the contents of synchronized map and invalidate the k iterator.

...

This compliant solution synchronizes on the map view instead of the set view. mapView field rather than on the setView field:

Code Block
bgColor #ccccff
// map has package-private accessibility 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, rather notthan set for (Integer k : setsetView) { // ... } } }

This code is compliant because the map's underlying structure cannot be changed when an iteration is in progressduring the iteration.

Risk Assessment

Synchronizing on a collection view instead of the collection object can cause nondeterministic behavior.

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]

Automated Detection

Some static analysis tools are capable of detecting violations of this rule.

Bibliography

Issue Tracking

||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name||
|F|M|F|1270825291208|          |dmohindr|suggested => "HashMap is 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."|

...

Image Added Image Added Image AddedImage Removed      12. Locking (LCK)      LCK05-J. Synchronize access to static fields that may be modified by untrusted code