| 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: |
...
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)
| Wiki Markup |
|---|
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 Block | ||||
|---|---|---|---|---|
| =
| |||
} // 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. However, because {{Set}} is synchronized instead of {{Map}}, 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.
...
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
| Wiki Markup |
|---|
\[[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] |
...
...
12. Locking (LCK) LCK05-J. Synchronize access to static fields that may be modified by untrusted code