Concurrenthashmap need to know the details

1, public V get (object key) does not involve locks, that is, the acquisition of objects without using locks;
2, KeySet (). iterator () and keys (), gets the iterator, enumeration variables are single-threaded access security, multi-threaded access to either generate multiple iterator, enumeration (by invoking the appropriate fetch method), It is either synchronized with the CONCURRENTHASHMAP variable for the lock (synchronized the variable); Concurrenthashmap variable is multithreaded access security, although it is multi-threaded access, in most cases there should be no lock contention;
3, put, remove method to use the lock, but there is no need to lock contention, because Concurrenthashmap will cache the variable into multiple segment, each segment has a lock, as long as more than one thread access is not a segment there is no lock contention, There is no blockage, each thread with its own lock, concurrenthashmap by default generates 16 segment, that is, allow 16 threads concurrent updates and as far as possible no lock contention;
4, Iterator, enumeration obtained objects, not necessarily with other update thread synchronization, obtained object may be the object before the update, concurrenthashmap allow one side to update, one side traversal, the key is not traversed to the general can show value update;
5, in some cases this inconsistency is allowed, if the need for maximum performance, throughput, then just use Concurrenthashmap.

A brief summary of Concurrenthashmap:

1, public V get (object key) does not involve locks, that is, the acquisition of objects without using locks;

2, put, remove method to use the lock, but there is no need to lock contention, because Concurrenthashmap will cache the variable into multiple segment, each segment has a lock, as long as more than one thread access is not a segment there is no lock contention, There is no blockage, each thread with its own lock, concurrenthashmap by default generates 16 segment, that is, allow 16 threads concurrent updates and as far as possible no lock contention;

3, the use of iterator objects, is not necessarily synchronized with other update threads, the obtained object may be the object before the update, concurrenthashmap allow one side to update, one side traversal, that is, when the iterator object traversal, Concurrenthashmap can also perform remove,put operations, and the traversed data will change with the output of the remove,put operation, so if you want to traverse all the current data, either synchronize with the CONCURRENTHASHMAP variable for the lock ( Synchronized the variable), or use the Copiediterator wrapper iterator to copy all the data from the current collection, but the resulting iterator is not allowed to take the remove operation.

Different points of Hashtable and Concurrenthashmap:

1, Hashtable to get,put,remove all use synchronous operation, its synchronization level is the Hashtable to synchronize, that is, if the thread is traversing the collection, other threads are temporarily unable to use the collection, This undoubtedly makes it easy to influence performance and throughput, resulting in a single point. And Concurrenthashmap is different, it only to put,remove operation using synchronous operation, get operation does not affect, see the above 1th, 2 points, the current concurrenthashmap such a practice for some thread-demanding programs, There is still a lack of, corresponding to such procedures, if not consider the performance and throughput issues, the personal feel that the use of Hashtable is more appropriate;

2, Hashtable when using iterator traversal, if other threads, including this thread to Hashtable Put,remove and other update operations, will throw Concurrentmodificationexception exception, But if you use Concurrenthashmap, you will not have to consider this issue, please see the 3rd above for details;

Before you start, what's the next map?

The map is explained in Javadoc as follows:

An object, the maps keys to values. A map cannot contain duplicate keys; Each key can map to the most one value.

This interface takes the place of the Dictionary class, which is a totally abstract class rather than an interface.

The map interface provides three collection views, which allow a maps ' s contents to be viewed as a set of keys, collection of values, or set of key-value mappings.

From the above, map is used to store the "Key-value" element pair, which maps a key to one and only one value.

Map can use a variety of implementations, HASHMAP implementation of the use of a hash table, and TreeMap is a red-black tree.

1. Hashtable and HashMap

These two classes are mainly different in the following ways:

Both Hashtable and HashMap implement the map interface, but the Hashtable implementation is based on the dictionary abstract class.

In HashMap, NULL can be used as a key with only one key, and one or more keys can have a value of NULL. When the Get () method returns a null value, it can indicate that the key is not in the HashMap, or that the value corresponding to the key is null. Therefore, the get () method cannot be used in HashMap to determine whether a key exists in HashMap and should be judged by the ContainsKey () method. In Hashtable, either key or value cannot be null.

The biggest difference between the two classes is that Hashtable is thread-safe and its methods are synchronized and can be used directly in multithreaded environments. And HashMap is not thread-safe. In a multithreaded environment, you need to implement the synchronization mechanism manually. Therefore, a method is provided in the collections class that returns a synchronous version of HashMap for multithreaded environments:

Java code

1. Public static <K,V> map<k,v> Synchronizedmap (map<k,v> m) {
2. return New Synchronizedmap<k,v> (m);
3. }

The method returns an instance of Synchronizedmap. The Synchronizedmap class is a static inner class that is defined in collections. It implements the map interface and implements each of these methods, which is controlled synchronously by the Synchronized keyword.

2. Potential thread-safety issues

As mentioned above, collections provides a concurrent version of Synchronizedmap for HashMap. The methods in this version are synchronized, but this does not mean that the class is thread safe. At some point there are some unexpected results.

As in the following code:

Java code

1. //SHM is an example of Synchronizedmap
2. if (Shm.containskey (' key ')) {
3. Shm.remove (key);
4. }

This code is used to determine if this element exists before deleting an element from the map. The ContainsKey and Reomve methods are synchronous, but the whole code is not. Consider a usage scenario in which thread a executes the ContainsKey method to return True, ready to perform a remove operation, when another thread B starts execution, the ContainsKey method returns True, and then the remove operation is performed And then thread A then executes the remove operation and finds that there is no such element at this time. One way to make sure this code works as we want is to synchronize the code, but it's too expensive.

This problem changes significantly when iterating. The Map collection provides a total of three ways to return a collection of key, value, and key-value pairs, respectively:

Java code

1. Set<k> KeySet ();
3. Collection<v> values ();
5. Set<map.entry<k,v>> EntrySet ();

On the basis of these three methods, we generally access the elements of the map in the following ways:

Java code

1. Iterator keys = Map.keyset (). Iterator ();
3. while (Keys.hasnext ()) {
4. Map.get (Keys.next ());
5. }

One place to note here is that the resulting keyset and iterators are a "view" of the elements in the map, not "replicas". The problem also arises here, when a thread is iterating over an element in a map, another thread may be modifying its elements. At this point, it may be thrown when iterating over elementsConcurrentModificationException异常。为了解决这个问题通常有两种方法，一是直接返回元素的副本，而不是视图。这个可以通过

The ToArray () method of the collection class is implemented, but the way the replicas are created is less efficient than before, especially in the case of many elements, and the other way is to lock the entire set when iterating, which makes it less efficient.

3. A better choice: Concurrenthashmap

The Concurrentmap interface and one of its implementation class Concurrenthashmap are added to the JAVA5. The CONCURRENTHASHMAP provides a different locking mechanism than the Hashtable and Synchronizedmap. The locking mechanism used in Hashtable is to lock the entire hash table at once, so that only one thread can manipulate it at the same time, while the Concurrenthashmap locks one bucket at a time. Concurrenthashmap By default, the hash table is divided into 16 buckets, such as get,put,remove, such as the common operation of only the current need to lock the bucket. This way, the original can only one thread into, but now can have 16 write thread execution, concurrency performance improvement is obvious.

The 16 threads mentioned above refer to a write thread, while the read operation does not require a lock for most of the time. It is only necessary to lock the entire hash table when working with size.

In terms of iterations, Concurrenthashmap uses a different iterative approach. In this iterative approach, when iterator is created, the collection is no longer thrown concurrentmodificationexception and replaced by new data at the time of the change without affecting the original data. The iterator is completed before replacing the head pointer with the new data, so that the iterator thread can use the old data, and the write thread can complete the change concurrently.

Concurrenthashmap need to know the details