NOTES: Java Concurrency programming Practice 1

Java 5.0 adds Concurrenthashmap, a replacement for synchronized hash-based Map implementations, and Copyonwritearraylist, a replacement for synchronized List implementations for cases where traversal is the D Ominant operation. The new Concurrentmap interface adds support for common compound actions such as put-if-absent, replace, and cond Itional Remove.

Java 5.0 also adds the new collection types, Queue and blockingqueue. A Queue is intended to hold a set of elements temporarily while they await processing. Several implementations is provided, including Concurrentlinkedqueue, a traditional FIFO queue, and Priorit Yqueue, a (non concurrent) priority ordered queue.

Java 6 adds concurrentskiplistmap and Concurrentskiplistset, which is concurrent replacements for a SYN chronized sortedmap or SortedSet (such as treeMap or TReeSet wrapped with sync Hronizedmap).

First we say, replace the implementation of synchronous HashMap Concurrenthashmap, such as Hashtable, wrote here suddenly thought of an interview question:

How do you make HashMap's size () method thread-safe without using locks? (This is to want you to understand the source of concurrenthashmap, it is easier to understand the interviewer to ask what content)

There is one more important thing:

The size () provided by Concurrenthashmap, IsEmpty () are approximate exact values and are not exactly the correct values, which also correspond to the semantics of the concurrent programming environment.

Specifically how to achieve, we can see the source code is described in this way:

http://www.iteye.com/topic/1103980

http://www.iteye.com/topic/344876

The more detailed: HashMap is divided into segment, and then on the different segment above the lock, operation.

Concurrenthashmap's size operation also uses a more ingenious way to avoid locking all segment as much as possible. We mentioned earlier that there is a Modcount variable in the segment, which represents the number of operations that affect the amount of elements in the segment, this value only increases, and the size operation iterates through the segment two times. The Modcount value of the segment is recorded each time, and then two times the modcount is compared, if the same, it means that there has not been a write operation, the result of the original traversal is returned, if not the same, the process is repeated again, if not the same, It is necessary to lock all the segment and then one through.

 Public intsize () {//Try a few times to get accurate count. On failure due to//continuous async changes in table, resort to locking.        FinalSegment<k,v>[] Segments = This. Segments; intsize; BooleanOverflow//true if size overflows        LongSum//Sum of modcounts        Longlast = 0L;//Previous sum        intretries =-1;//First iteration isn ' t retry        Try {             for (;;) {                if(retries++ = =Retries_before_lock) {                     for(intj = 0; J < Segments.length; ++j) Ensuresegment (J). Lock (); //Force Creation} sum= 0L; Size= 0; Overflow=false;  for(intj = 0; J < Segments.length; ++j) {Segment<K,V> seg =Segmentat (segments, j); if(Seg! =NULL) {sum+=Seg.modcount; intc =Seg.count; if(C < 0 | | (size + C) < 0) Overflow=true; }                }                if(Sum = =Last ) Break; Last=sum; }        } finally {            if(Retries >Retries_before_lock) {                 for(intj = 0; J < Segments.length; ++j) Segmentat (segments, J). Unlock (); }        }        returnOverflow?Integer.MAX_VALUE:size; }

This can correspond to the above question.

Besides, this Copyonwritearray fit scenario is: Copyonwritearraylist is suitable for scenarios where reading is much larger than write operations, such as caching. When the modification occurs, copy is made, the new and old versions are separated, and the high performance is guaranteed to be read-oriented.

Notes: Java Concurrency programming Practice 1