Java Collection (--CONCURRENTHASHMAP) source code Analysis

Concurrenthashmap uses a lock separation technique that uses multiple locks to control changes to different parts of the hash table . using Segments (Segment) to represent these different parts, each segment is actually a small hash table with its own lock . As long as multiple modification operations occur on different segments, they can be performed concurrently .

Some methods require cross-sections , such as size () and Containsvalue (), and they may need to lock the entire table rather than just a segment, which requires all segments to be locked sequentially , after the operation is complete , and the locks for all segments are released sequentially .

The segment array is final , and its member variables are actually final . make sure that no deadlocks occur because the order in which the locks are obtained is fixed .

Concurrenthashmap allows multiple read operations to be performed concurrently , and read operations do not require locking . in HashMap, if an element is allowed to be added or deleted in the middle of the hash chain, the read operation will get inconsistent data without locking.

Segment inherits the Reentrantlock, indicating that each Segment can be used as a lock.

Final Segment<k,v>[] segments; Static Final class Hashentry<k,v> {       final  K key;        Final int Hash;        volatile V value;        Final Hashentry<k,v> next;  }  

Except that value is not final , the other values are final , which means that nodes cannot be added or removed from the middle or tail of the hash chain , because this requires modifying the next reference value. And next is final, and all of the node modifications can only start with the head.

Ensure that the read operation sees the most recent value and sets the value to volatile, which avoids locking (weak synchronization).

by default , the internal is created by the concurrency level of . For each segment capacity, the default is 16.

The number of hash slots in each segment is 2^n.

The reason to traverse the hash chain without locking is that the chain pointer next is final.

Through the coordination mechanism of the count variable, get can read to almost the latest data, although it may not be up to date. To get the latest data, only full synchronization is used.

next in each hashentry is final , unable to add a subsequent entry to the last element of the list so a new entry implementation can only be inserted through the header node . As shown in the following:

The get method in segment:

V Get (Object key,inthash) {         //number of entry present in segment//count it uses volatile to modify//Every time you judge the count variable, even if the other thread changes, segment will show up .     if(count! = 0) {//①, watch this .Hashentry<k,v> e =GetFirst (hash); node while(E! =NULL) {              if(E.hash = = Hash &&key.equals (E.key)) {V v=E.value; if(V! =NULL)//②, watch this .                    returnv; //need to re-examine                 returnReadvalueunderlock (e);//Recheck} e=E.next; }       }       return NULL; }  

The above code does not use a lock to synchronize , only to determine whether the obtained entry value is null, is null when the lock is used to get again.

Get code between ① and ②, another thread added a entry, if another thread added this entry is exactly what we want to get, this thing is more subtle.

The Newentry object is created by using new Hashentry (k K, v V, hashentry next). If the other thread is just the new object, the current thread is get it. Because there is no synchronization, it is possible that the Newentry object that the current thread obtains is an object reference that is not fully constructed. So we need to judge: if (v! = null) If it is an incomplete object, get it again using the lock method.

is it possible to put in a value null entry? No, it has been checked and this situation throws an exception.

Suppose our list element is:e1-> E2, E3, E4 we are going to delete E3 this entry, because Hashentry is immutable in next, so we can't directly point E2 next to E4, but The node before the node to be deleted copies a copy, forming a new linked list.

Concurrenthashmap iterators are not fast-fail , so other threads Add/remove elements during the iteration , do not throw exceptions, and do not reflect changes in the elements.

Java Collection (--CONCURRENTHASHMAP) source code Analysis