public Class ConcurrentHashMap

Retrievals

Retrievals may overlap updates. (This is the same policy as ConcurrentReaderHashMap.) Successful retrievals using get(key) and containsKey(key) usually run without locking. Unsuccessful retrievals (i.e., when the key is not present) do involve brief synchronization (locking). Because retrieval operations can ordinarily overlap with update operations (i.e., put, remove, and their derivatives), retrievals can only be guaranteed to return the results of the most recently completed operations holding upon their onset. Retrieval operations may or may not return results reflecting in-progress writing operations. However, the retrieval operations do always return consistent results -- either those holding before any single modification or after it, but never a nonsense result. For aggregate operations such as putAll and clear, concurrent reads may reflect insertion or removal of only some entries.

Iterators and Enumerations (i.e., those returned by keySet().iterator(), entrySet().iterator(), values().iterator(), keys(), and elements()) return elements reflecting the state of the hash table at some point at or since the creation of the iterator/enumeration. They will return at most one instance of each element (via next()/nextElement()), but might or might not reflect puts and removes that have been processed since they were created. They do not throw ConcurrentModificationException. However, these iterators are designed to be used by only one thread at a time. Passing an iterator across multiple threads may lead to unpredictable results if the table is being concurrently modified.

Updates

This class supports a hard-wired preset concurrency level of 32. This allows a maximum of 32 put and/or remove operations to proceed concurrently. This level is an upper bound on concurrency, not a guarantee, since it interacts with how well-strewn elements are across bins of the table. (The preset value in part reflects the fact that even on large multiprocessors, factors other than synchronization tend to be bottlenecks when more than 32 threads concurrently attempt updates.) Additionally, operations triggering internal resizing and clearing do not execute concurrently with any operation.

There is NOT any support for locking the entire table to prevent updates. This makes it imposssible, for example, to add an element only if it is not already present, since another thread may be in the process of doing the same thing. If you need such capabilities, consider instead using the ConcurrentReaderHashMap class.

This class may be used as a direct replacement for java.util.Hashtable in any application that does not rely on the ability to lock the entire table to prevent updates. As of this writing, it performs much faster than Hashtable in typical multi-threaded applications with multiple readers and writers. Like Hashtable but unlike java.util.HashMap, this class does NOT allow null to be used as a key or value.