A hash table that supports mostly-concurrent reading, but exclusive writing. Because reads are not limited to periods without writes, a concurrent reader policy is weaker than a classic reader/writer policy, but is generally faster and allows more concurrency. This class is a good choice especially for tables that are mainly created by one thread during the start-up phase of a program, and from then on, are mainly read (with perhaps occasional additions or removals) in many threads. If you also need concurrency among writes, consider instead using ConcurrentHashMap.

Successful retrievals using get(key) and containsKey(key) usually run without locking. Unsuccessful ones (i.e., when the key is not present) do involve brief synchronization (locking). Also, the size and isEmpty methods are always synchronized.

Because retrieval operations can ordinarily overlap with writing 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. In those rare contexts in which you use a hash table to synchronize operations across threads (for example, to prevent reads until after clears), you should either encase operations in synchronized blocks, or instead use java.util.Hashtable.

This class also supports optional guaranteed exclusive reads, simply by surrounding a call within a synchronized block, as in
ConcurrentReaderHashMap t; ... Object v;
synchronized(t) { v = t.get(k); }
But this is not usually necessary in practice. For example, it is generally inefficient to write:

   ConcurrentReaderHashMap t; ...            // Inefficient version
   Object key; ...
   Object value; ...
   synchronized(t) { 
     if (!t.containsKey(key))
       t.put(key, value);
       // other code if not previously present
     }
     else {
       // other code if it was previously present
     }
   }

Instead, if the values are intended to be the same in each case, just take advantage of the fact that put returns null if the key was not previously present:

   ConcurrentReaderHashMap t; ...                // Use this instead
   Object key; ...
   Object value; ...
   Object oldValue = t.put(key, value);
   if (oldValue == null) {
     // other code if not previously present
   }
   else {
     // other code if it was previously present
   }

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. Sharing an iterator across multiple threads may lead to unpredictable results if the table is being concurrently modified. Again, you can ensure interference-free iteration by enclosing the iteration in a synchronized block.

This class may be used as a direct replacement for any use of java.util.Hashtable that does not depend on readers being blocked during updates. Like Hashtable but unlike java.util.HashMap, this class does NOT allow null to be used as a key or value. This class is also typically faster than ConcurrentHashMap when there is usually only one thread updating the table, but possibly many retrieving values from it.

[ Introduction to this package. ]