Concurrent collections. Java 8

Concurrent collections.

What are the reasons to use new concurrent collections when we can use old plain collections using wrappers like Collections.synchronized(List/Set/Map)? The problem in this case will be that all accesses to the collection will use one lock. In its turn this will slow down performance.

We can ask what is the price in this case? For example take a look at HashTable and ConcurrentHashMap by the following link: https://www.ibm.com/developerworks/java/library/j-jtp07233/index.html.

Here are the results:
Threads    ConcurrentHashMap    Hashtable
1    1.00    1.03
2    2.59    32.40
4    5.58    78.23
8    13.21    163.48
16    27.58    341.21
32    57.27    778.41

Absolute numbers are not important but it is more valid to compare relative numbers.

What can we do about it? Maybe it will be better to write our own implementation of concurrent collection? It it possible but hard to achieve and more over there are already good implementations. Many useful concurrent collections are located at  java.util.concurrent package.

Concurrent collections make synchronized collections largely obsolete.

That way instead of HashMap one can use ConcurrentHashMap.
In case when a number of search iterations outnumbers the number of adding or removing operations one can use CopyOnWriteArrayList instead of ArrayList.

As for the Queue implementations there are a lot of implementations:

    1. LinkedBlockingQueue — an optionally bounded FIFO blocking queue backed by linked nodes. An optionally-bounded blocking queue based on linked nodes.  Linked queues typically have higher throughput than array-based queues but less predictable performance in most concurrent applications. The optional capacity bound constructor argument serves as a way to prevent excessive queue expansion. The capacity, if unspecified, is equal to Integer.MAX_VALUE. Linked nodes are dynamically created upon each insertion unless this would bring the queue above capacity.
   
    2. ArrayBlockingQueue — a bounded FIFO blocking queue backed by an array. A bounded blocking queue backed by an array.
   
    3. ConcurrentLinkedQueue - An unbounded thread-safe queue based on linked nodes. This queue orders elements FIFO (first-in-first-out). This implementation employs an efficient non-blocking algorithm based on one described in Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms by Maged M. Michael and Michael L. Scott.
   
    It is not obvious which implementation to use? It depends. One should choose the implementation based on tests.
   
    4. PriorityBlockingQueue — an unbounded blocking priority queue backed by a heap. An unbounded blocking queue that uses the same ordering rules as class PriorityQueue and supplies blocking retrieval operations.

    5. DelayQueue — a time-based scheduling queue backed by a heap. An unbounded blocking queue of Delayed elements, in which an element can only be taken when its delay has expired. 
   
    6. SynchronousQueue — a simple rendezvous mechanism that uses the BlockingQueue interface. Synchronous queues are similar to rendezvous channels used in CSP and Ada. They are well suited for handoff designs, in which an object running in one thread must sync up with an object running in another thread in order to hand it some information, event, or task.

 7. In JDK 7, TransferQueue is a specialized BlockingQueue in which code that adds an element to the queue has the option of waiting (blocking) for code in another thread to retrieve the element. TransferQueue has a single implementation:

    LinkedTransferQueue — an unbounded TransferQueue based on linked nodes. This implementation outperforms SynchronousQueue by factor of 3 to 14. See http://cs.oswego.edu/pipermail/concurrency-interest/2009-February/005886.html.
   
Deques and work stealing.
    Just as blocking queues lend themselves to the producer-consumer pattern, deques lend themselves to a related pattern called work stealing.