5 basic build module-concurrent container, build module concurrent container

5 basic build module-concurrent container, build module concurrent container

Concurrent container

Using concurrent containers instead of synchronous containers provides performance, which greatly improves scalability and reduces risks.

Java 5.0 adds two new container types: Queue and BlockingQueue. The Queue implementation includes concurrentincluqueue, which is a traditional first-in-first-out Queue with PriorityQueue (non-concurrent) priority Queue. Operations on the Queue will not be blocked. If the Queue is empty, the operation to obtain the Queue element will return a null value.

BlockingQueue extends the Queue and adds blocking insertion and retrieval operations. If the queue is empty, the operation to get the queue element will be blocked until an available element appears in the queue. If the queue is full (for a bounded Queue), the insert element operation will be blocked until available space appears in the queue.

ConcurrentHashMap and HashMap are also hash-based maps, but they completely use a no-need locking policy to provide higher concurrency and scalability. ConcurrentHashMap does not use the same lock for synchronization in each method, but uses a finer granularity locking mechanism to achieve greater sharing, that is, segment locks. In this mechanism, any number of threads can concurrently access Map. the threads that execute read operations and write operations can be concurrently performed, and a certain number of write threads can modify Map concurrently. The ConcurrentHashMap container does not throw ConcurrentModificationException during iteration, so it does not need to be locked during iteration. The iterator returned by ConcurrentHashMap has a weak consistency (Weakly Consistent), rather than "even if it fails ". The weak consistency iterator can tolerate concurrent modifications. When an iterator is created, it traverses all elements and can (but is not guaranteed) modify the elements and respond to the container after the iteration is built. In this case, there are still factors to weigh. For methods that need to calculate the entire Map, such as size and isEmpty, the semantics of these methods is slightly reduced to reflect the concurrency characteristics of the container. The size may have expired in the calculation result. It is actually an estimate, so the size returns an approximate value rather than an exact value.

Additional atomic operations

ConcurrentHashMap cannot be locked for exclusive access, so we cannot use the client to lock to create new atomic operations. These composite operations all implement atomic operations, such as "add If no", "Remove If relative (Remove-If-Equal) replace-If-Equal.

CopyOnWriteArrayList

CopyOnWriteArrayList is used to replace the synchronous List, which provides better concurrency performance in some cases. In addition, containers do not need to be locked or copied during iteration. The thread security of the "Copy-On-Write" container is that as long as an immutable object of fact is correctly published, lock synchronization is not required to access this object. Each time you modify a container, a new container copy is created and re-released to achieve variability. The "copy upon write" container iteration operation does not throw ConcurrentModificationException, and the elements returned are exactly the same as those when the iterator is created, without the impact of subsequent modification. The modify operation of the "copy upon writing" container requires a certain amount of overhead, so it should be used only when the iterative operation is much more than the modification operation.