Java concurrency Programming (iv) Concurrent containers

Concurrent containers

Java 5.0 provides a variety of concurrent containers to improve the performance of the synchronization container.

The synchronization container is the serialization of all access to the container to implement their thread security. The cost is severely reduced and released, and throughput is severely degraded when multiple threads compete for a lock on a container.

Concurrent containers are designed for concurrent access to multiple threads. Java 5.0 adds Concurrenthashmap , which replaces the synchronous, hash-based MAP, with the addition of the Copyonwritearraylist , which is used to override the synchronization in the case of the traversal operation being the primary operation. List.

Java 5.0 also adds two central container types:Queue and blockingqaueue.

Queue is used to temporarily save the element to be processed. It provides several implementations, including Concurrentlinkedqueue, which is a traditional FIFO queue. Priorityqueue, this is a (non-concurrent) Priority queue. Operations on the queue are not blocked, and if the queue is empty, the operation that gets the element returns a null value. Although you can use list to simulate the behavior of a queue-in fact, it is through LinkedList to implement the queue, but also need a queue class, because it can eliminate the random access to the list of requirements, so as to achieve more efficient concurrency.

The blockingqueue extends the Queue, adding blocking insertions and fetches to operations. If the queue is empty, the operation that gets the element will block until an available element appears in the queue. If the queue is full (for bounded queues), the Insert element will block until there is space available in the queue. This is very useful in the producer-consumer model.

Just as Concurrenthashmap is used instead of hash-based synchronization Map,java 6 also introduces Concurrentskiplistmap and concurrentskiplistset , As concurrent substitutes for synchronized SortedMap and SortedSet, respectively. (for example, TreeMap or TreeSet packaged in Synchronizedmap).

Concurrenthashmap

On the basic structure, CONCURRENTHASHMAP is the same as HASHMAP, but it uses a completely different locking strategy to provide higher concurrency and scalability. It uses a finer -grained locking mechanism to achieve greater sharing, a mechanism called segmented locks (lock Striping).

With a segmented lock, any number of read threads can access the map concurrently, the thread that performs the read operation and the thread that performs the write operation can access the map concurrently, and a certain number of write threads can concurrently modify the map. The result of Concurrenthashmap is that higher throughput will be achieved in the context of concurrent access, while only minimal performance is lost in a single-threaded environment.

Concurrenthashmap with other concurrent containers enhances the synchronization container class: They provide iterators that do not throw concurrentmodificationexception, so you do not need to lock the container during the iteration. The iterator returned by Concurrenthashmap has weak consistency rather than a "timely failure". A weakly consistent iterator can tolerate concurrent modifications, and when an iterator is created, it iterates through the existing elements and can reflect the modifications to the container after the iterator is constructed.

Despite these improvements, there are still some factors that need to be weighed. For some methods that need to be computed on the entire map, such as size and isEmpty, the implication of these methods is slightly diminished to reflect the concurrency characteristics of the container. Because the result returned by the size method may have expired at the time of calculation, it is actually an estimate, allowing the size to return an approximate value instead of an exact value. While this may seem disturbing, the fact that the size and IsEmpty methods are less useful in concurrent environments because their return values are always changing. As a result, the need for these operations has been weakened in exchange for performance optimizations for other more important operations, including get, put, ContainsKey, and remove.

Compared with Hashtable and Synchronizedmap, Concurrenthashmap has more advantages and less disadvantage. Therefore, in most cases, using concurrenthashmap instead of synchronous MAP can further improve the scalability of the code. You can discard the use of Concurrenthashmap only if the application needs to lock the map for exclusive access.

Copyonwritearraylist

Copyonwritearraylist is used instead of synchronizing lists, which in some cases provides better concurrency performance. There is no need to lock or copy the container in an iterative device. (similar to Copyonwritearrayset).

The thread safety of the copy-on-write (Copy-on-write) container is that, as long as a fact-immutable object is published correctly, no further synchronization is required to access the object. Each time a modification is made, a new copy of the container is created and republished, allowing for variability. The iterator to the copy-on-write container retains a reference to the underlying underlying array, which is currently at the beginning of the iterator, and because he is not modified, it is only necessary to ensure the visibility of the array content when synchronizing it. As a result, multiple threads can iterate over the container without interfering with each other or modifying the container's threads to interfere with each other.

Obviously, the underlying array is copied whenever the container is modified, which requires some overhead, especially if the container is large in size. The "Copy on write" container should be used only when the operation is far more than the modification operation. This guideline is a good description of many event notification systems:

When you distribute notifications, you need to iterate through the registered listener lists and invoke each listener, and in most cases, registering and Unregistering event listeners is much less than the action of receiving time notifications.

Java concurrency Programming (iv) Concurrent containers