Map.forEach

[Doug Lea]

On 12/10/2013 01:15 PM, Martin Buchholz wrote:
> Perhaps Doug could provide history on the intent of ConcurrentMap.

See the package-level docs in java.util.concurrent that compare
Hashtable to ConcurrentMap, implying that it might not be a good idea
to now retrospectively declare Hashtable as a ConcurrentMap even though,
through the magic of defaults, they share methods.

Pasting...


The "Concurrent" prefix used with some classes in this package is a shorthand 
indicating several differences from similar "synchronized" classes. For example 
java.util.Hashtable and Collections.synchronizedMap(new HashMap()) are 
synchronized. But ConcurrentHashMap is "concurrent". A concurrent collection is 
thread-safe, but not governed by a single exclusion lock. In the particular case 
of ConcurrentHashMap, it safely permits any number of concurrent reads as well 
as a tunable number of concurrent writes. "Synchronized" classes can be useful 
when you need to prevent all access to a collection via a single lock, at the 
expense of poorer scalability. In other cases in which multiple threads are 
expected to access a common collection, "concurrent" versions are normally 
preferable. And unsynchronized collections are preferable when either 
collections are unshared, or are accessible only when holding other locks.

Most concurrent Collection implementations (including most Queues) also differ 
from the usual java.util conventions in that their Iterators and Spliterators 
provide weakly consistent rather than fast-fail traversal:

     they may proceed concurrently with other operations
     they will never throw ConcurrentModificationException
     they are guaranteed to traverse elements as they existed upon construction 
exactly once, and may (but are not guaranteed to) reflect any modifications 
subsequent to construction.