A lock-free alternate implementation of
java.util.concurrent.ConcurrentHashMapwith
primitive long keys, better scaling properties and
generally lower costs. The use of
long keys allows for faster
compares and lower memory costs. The Map provides identical correctness
properties as ConcurrentHashMap. All operations are non-blocking and
multi-thread safe, including all update operations.
NonBlockingHashMapLong scales substatially better than
java.util.concurrent.ConcurrentHashMap for high update rates, even with a large
concurrency factor. Scaling is linear up to 768 CPUs on a 768-CPU Azul
box, even with 100% updates or 100% reads or any fraction in-between.
Linear scaling up to all cpus has been observed on a 32-way Sun US2 box,
32-way Sun Niagra box, 8-way Intel box and a 4-way Power box.
The main benefit of this class over using plain
org.cliffc.high_scale_lib.NonBlockingHashMap with
Long keys is
that it avoids the auto-boxing and unboxing costs. Since auto-boxing is
automatic, it is easy to accidentally cause auto-boxing and negate
the space and speed benefits.
This class obeys the same functional specification as
java.util.Hashtable, and includes versions of methods corresponding to
each method of Hashtable. However, even though all operations are
thread-safe, operations do not entail locking and there is
not any support for locking the entire table in a way that
prevents all access. This class is fully interoperable with
Hashtable in programs that rely on its thread safety but not on
its synchronization details.
Operations (including put) generally do not block, so may
overlap with other update operations (including other puts and
removes). Retrievals reflect the results of the most recently
completed update operations holding upon their onset. For
aggregate operations such as putAll, concurrent retrievals may
reflect insertion or removal of only some entries. Similarly, Iterators
and Enumerations return elements reflecting the state of the hash table at
some point at or since the creation of the iterator/enumeration. They do
not throw
ConcurrentModificationException. However,
iterators are designed to be used by only one thread at a time.
Very full tables, or tables with high reprobe rates may trigger an
internal resize operation to move into a larger table. Resizing is not
terribly expensive, but it is not free either; during resize operations
table throughput may drop somewhat. All threads that visit the table
during a resize will 'help' the resizing but will still be allowed to
complete their operation before the resize is finished (i.e., a simple
'get' operation on a million-entry table undergoing resizing will not need
to block until the entire million entries are copied).
This class and its views and iterators implement all of the
optional methods of the
Map and
Iteratorinterfaces.
Like
Hashtable but unlike
HashMap, this class
does not allow null to be used as a value.