...
| Wiki Markup |
|---|
This technique is also called client-side locking \[[Goetz 2006|AA. Java References#GoetzBibliography#Goetz 06]\] because the class holds a lock on an object that might be accessible to other classes. Client-side locking is not always an appropriate strategy; see guideline [LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy] for more information. |
...
| Wiki Markup |
|---|
This noncompliant code example defines the {{KeyedCounter}} class that is not thread-safe. Although the {{HashMap}} is wrapped in a {{synchronizedMap}}, the overall increment operation is not atomic \[[Lee 2009|AA. Java References#LeeBibliography#Lee 09]\]. |
| Code Block |
|---|
|
final class KeyedCounter {
private final Map<String, Integer> map =
Collections.synchronizedMap(new HashMap<String, Integer>());
public void increment(String key) {
Integer old = map.get(key);
int oldValue = (old == null) ? 0 : old.intValue();
if (oldValue == Integer.MAX_VALUE) {
throw new ArithmeticException("Out of range");
}
map.put( key, oldValue + 1);
}
public Integer getCount(String key) {
return map.get(key);
}
}
|
...
| Wiki Markup |
|---|
The {{ConcurrentHashMap}} class used in this compliant solution provides several utility methods for performing atomic operations and is often a good choice for algorithms that must scale \[[Lee 2009|AA. Java References#LeeBibliography#Lee 09]\]. |
| Code Block |
|---|
|
final class KeyedCounter {
private final ConcurrentMap<String, AtomicInteger> map =
new ConcurrentHashMap<String, AtomicInteger>();
public void increment(String key) {
AtomicInteger value = new AtomicInteger();
AtomicInteger old = map.putIfAbsent(key, value);
if (old != null) {
value = old;
}
if (value.get() == Integer.MAX_VALUE) {
throw new ArithmeticException("Out of range");
}
value.incrementAndGet(); // Increment the value atomically
}
public Integer getCount(String key) {
AtomicInteger value = map.get(key);
return (value == null) ? null : value.get();
}
// Other accessors ...
}
|
| Wiki Markup |
|---|
According to Section 5.2.1., "ConcurrentHashMap" of the work of Goetz and colleagues \[[Goetz 2006|AA. Java References#GoetzBibliography#Goetz 06]\]: |
ConcurrentHashMap, along with the other concurrent collections, further improve on the synchronized collection classes by providing iterators that do not throw ConcurrentModificationException, as a result eliminating the need to lock the collection during iteration. The iterators returned by ConcurrentHashMap are weakly consistent instead of fail-fast. A weakly consistent iterator can tolerate concurrent modification, traverses elements as they existed when the iterator was constructed, and may (but is not guaranteed to) reflect modifications to the collection after the construction of the iterator.
...
| Wiki Markup |
|---|
\[[API 2006|AA. Java References#APIBibliography#API 06]\]
\[[JavaThreads 2004|AA. Java References#JavaThreadsBibliography#JavaThreads 04]\] Section 8.2, "Synchronization and Collection Classes"
\[[Goetz 2006|AA. Java References#GoetzBibliography#Goetz 06]\] Section 4.4.1, "Client-side Locking," Section 5.2.1, "ConcurrentHashMap"
\[[Lee 2009|AA. Java References#LeeBibliography#Lee 09]\] "Map & Compound Operation" |
...
