Hashtable之所以效率低下主要是因为其实现使用了synchronized关键字对put等操作进行加锁，而synchronized关键字加锁是对整个对象进行加锁，也就是说在进行put等修改Hash表的操作时，锁住了整个Hash表，从而使得其表现的效率低下。
HashTable：使用了synchronized关键字对put等操作进行加锁;
ConcurrentHashMap JDK1.7：使用分段锁机制实现；
ConcurrentHashMap JDK1.8：则使用数组+链表+红黑树数据结构和CAS原子操作实现；
在JDK1.5~1.7版本，Java使用了分段锁机制实现ConcurrentHashMap
简而言之，ConcurrentHashMap在对象中保存了一个Segment数组，即将整个Hash表划分为多个分段；而每个Segment元素，它通过继承ReentrantLock来进行加锁，所以每次需要加锁的操作锁住的是一个Segment，这样只要保证每个Segment是线程安全的，也就实现了全局的线程安全；这样，在执行put操作时首先根据hash算法定位到元素属于哪个Segment，然后对该Segment加锁即可。因此，ConcurrentHashMap在多线程并发编程中可是实现多线程put操作。
concurrencyLevel：Segment数(并行级别、并发数)。默认是16，也就是说ConcurrentHashMap有16个Segments，所以理论上，这个时候，最多可以同时支持16个线程并发写，只要它们的操作分别分布在不同的Segment上。这个值可以在初始化的时候设置为其他值，但是一旦初始化以后，它是不可以扩容的。
rehash(注：Segment数组不能扩容，扩容是Segment数组某个位置内部的数组HashEntry<K,V>[]进行扩容)
在JDK1.7之前，ConcurrentHashMap是通过分段锁机制来实现的，所以其最大并发度受Segment的个数限制。因此，在JDK1.8中，ConcurrentHashMap的实现原理摒弃了这种设计，而是选择了与HashMap类似的数组+链表+红黑树的方式实现，而加锁则采用CAS和synchronized实现。简而言之：数组+链表+红黑树，CAS
tryPresize，扩容也是做翻倍扩容的，扩容后数组容量为原来的 2 倍。
transfer，将原来的tab数组的元素迁移到新的nextTab数组中。
CopyOnWriteArrayList是Java并发包中提供的一个并发容器，它是个线程安全的ArrayList，写操作通过创建底层数组的新副本来实现，是一种读写分离的并发策略，我们也可以称这种容器为"写时复制器"，Java并发包中类似的容器还有CopyOnWriteSet，不过在CopyOnWriteSet中任然是调用的是CopyOnWriteArrayList。
实现原理：
集合框架中的ArrayList是非线程安全的，Vector虽是线程安全的，但是它的锁同步机制十分简单所以性能较差。
而CopyOnWriteArrayList则提供了另一种不同的并发处理策略(读写分离)。CopyOnWriteArrayList容器允许并发读，读操作是无锁的，性能较高。至于写操作，比如向容器中添加一个元素，则首先将当前容器复制一份，然后在新副本上执行写操作，结束之后再将原容器的引用指向新容器。
新增元素的操作：
首先获取锁然后生成一个新的数组+1，这时候再将新数组的新增位置添加新元素，最后替换原数组就行了。
public boolean add(E e) {
final ReentrantLock lock = this.lock; //获取锁
lock.lock();
try {
Object[] elements = getArray(); //获取原数组
int len = elements.length; //获取原数组个数
//拷贝一份原数组并+1，生成的新数组的len位置上增加元素
Object[] newElements = Arrays.copyOf(elements, len + 1);
newElements[len] = e;
setArray(newElements); //替换原数组
return true;
} finally {
lock.unlock(); //释放锁
}
}
删除元素的操作：
首先获取锁，将删除的元素之外的其他元素拷贝到新数组中，然后切换引用，将原数组引用指向新数组。
public E remove(int index) {
final ReentrantLock lock = this.lock; //获取锁
lock.lock();
try {
Object[] elements = getArray(); //获取原数组，并得出当前数组大小
int len = elements.length;
E oldValue = get(elements, index); //获取旧值，并计算索引位置
int numMoved = len - index - 1; //计算需要移动的元素个数
if (numMoved == 0) //表示是末尾，直接拷贝原数组0-(len-1)
setArray(Arrays.copyOf(elements, len - 1));
else {
Object[] newElements = new Object[len - 1]; //生成新数组并进行两次拷贝
System.arraycopy(elements, 0, newElements, 0, index);
System.arraycopy(elements, index + 1, newElements, index, numMoved);
setArray(newElements);
}
return oldValue;
} finally {
lock.unlock(); //解锁
}
}
读取元素的操作：
不需要获取锁
public E get(int index) {
return get(getArray(), index);
}
优点：
1、CopyOnWriteArrayList由于其"读写分离"的思想，遍历和修改操作分别作用在不同的数组，所以在使用迭代器进行遍历时候，不会抛出ConcurrentModificationException异常。
2、读操作性能很高，因为无需任何同步措施，比较适用于读多写少的并发场景。
缺点：
1、内存占用问题，每次执行写操作都要将原容器拷贝一份，数据量大时，对内存压力较大，可能会引起频繁GC。
2、无法保证实时性，Vector对于读写操作均加锁同步，可以保证读和写的强一致性。而CopyOnWriteArrayList的实现策略是写和读分别作用在新老不同数组上，在写操作执行过程中，读不会阻塞但读取到的却是为更新前的数据。
ConcurrentLinkedQueue是一个基于链接节点的无界线程安全队列，它采用先进先出的规则对节点进行排序，当我们添加一个元素的时候，它会添加到队列的尾部，当我们获取一个元素时，它会返回队列头部的元素。ConcurrentLinkedQueue采用了非阻塞方式实现。
ConcurrentLinkedQueue的结构
ConcurrentLinkedQueue由首节点Node head、尾节点Node tail组成，都用volatile修饰。而Node则由元素E item、下一节点Node next组成，都用volatile修饰。
每个节点（Node）由节点元素（item）和指向下一个节点的引用(next)组成，节点与节点之间就是通过这个next关联起来，从而组成一张链表结构的队列。
默认head节点元素为null，而tail等于head，即：head = tail = new Node(null)
入队，增加元素的操作
入队列就是将入队节点添加到队列的尾部，假设我们要在一个队列中依次插入4个节点，来看看下面的图来方便理解：
添加元素1：更新head节点的next节点为元素1节点，设置tail节点的next节点都指向元素1节点。
添加元素2：设置元素1节点的next节点为元素2节点，然后更新tail节点指向元素2节点。
添加元素3：设置元素2节点的next节点为元素3节点，然后设置tail节点的next节点为元素3节点。
添加元素4：设置元素3节点的next节点为元素4节点，然后更新tail节点指向元素4节点。
入队主要做两件事情：
第一是将入队节点设置成当前队列尾节点的下一个节点。
第二是更新tail节点，在入队列前如果tail节点的next节点不为空，则将入队节点设置成tail节点，如果tail节点的next节点为空，则将入队节点设置成tail的next节点，所以tail节点不总是尾节点。
public boolean offer(E e) {
if (e == null) throw new NullPointerException();
//入队前，创建一个入队节点
Node<E> n = new Node<E>(e);
retry:
//死循环，入队不成功反复入队。
for (;;) {
//创建一个指向tail节点的引用
Node<E> t = tail;
//p用来表示队列的尾节点，默认情况下等于tail节点。
Node<E> p = t;
for (int hops = 0; ; hops++) {
//获得p节点的下一个节点。
Node<E> next = succ(p);
//next节点不为空，说明p不是尾节点，需要更新p后在将它指向next节点
if (next != null) {
//循环了两次及其以上，并且当前节点还是不等于尾节点
if (hops > HOPS && t != tail)
continue retry;
p = next;
}
//如果p是尾节点，则设置p节点的next节点为入队节点。
else if (p.casNext(null, n)) {
//如果tail节点有大于等于1个next节点，则将入队节点设置成tair节点，更新失败了也没关系，因为失败了表示有其他线程成功更新了tair节点。
if (hops >= HOPS)
casTail(t, n); // 更新tail节点，允许失败
return true;
}
// p有next节点,表示p的next节点是尾节点，则重新设置p节点
else {
p = succ(p);
}
}
}
}
第一步定位尾节点。
tail节点并不总是尾节点，所以每次入队都必须先通过tail节点来找到尾节点，尾节点可能就是tail节点，也可能是tail节点的next节点。代码中循环体中的第一个if就是判断tail是否有next节点，有则表示next节点可能是尾节点。获取tail节点的next节点需要注意的是p节点等于p的next节点的情况，只有一种可能就是p节点和p的next节点都等于空，表示这个队列刚初始化，正准备添加第一次节点，所以需要返回head节点。获取p节点的next节点代码如下：
final Node<E> succ(Node<E> p) {
Node<E> next = p.getNext();
return (p == next) ? head : next;
}
第二步设置入队节点为尾节点。
p.casNext(null, n)方法用于将入队节点设置为当前队列尾节点的next节点，p如果是null表示p是当前队列的尾节点，如果不为null表示有其他线程更新了尾节点，则需要重新获取当前队列的尾节点。
hops的设计意图。
上面分析过对于先进先出的队列入队所要做的事情就是将入队节点设置成尾节点，doug lea写的代码和逻辑还是稍微有点复杂。那么我用以下方式来实现行不行？
public boolean offer(E e) {
if (e == null)
throw new NullPointerException();
Node<E> n = new Node<E>(e);
for (;;) {
Node<E> t = tail;
if (t.casNext(null, n) && casTail(t, n)) {
return true;
}
}
}
让tail节点永远作为队列的尾节点，这样实现代码量非常少，而且逻辑非常清楚和易懂。但是这么做有个缺点就是每次都需要使用循环CAS更新tail节点。如果能减少CAS更新tail节点的次数，就能提高入队的效率，所以doug lea使用hops变量来控制并减少tail节点的更新频率，并不是每次节点入队后都将 tail节点更新成尾节点，而是当 tail节点和尾节点的距离大于等于常量HOPS的值(默认等于1)时才更新tail节点，tail和尾节点的距离越长使用CAS更新tail节点的次数就会越少，但是距离越长带来的负面效果就是每次入队时定位尾节点的时间就越长，因为循环体需要多循环一次来定位出尾节点，但是这样仍然能提高入队的效率，因为从本质上来看它通过增加对volatile变量的读操作来减少了对volatile变量的写操作，而对volatile变量的写操作开销要远远大于读操作，所以入队效率会有所提升。
还有一点需要注意的是入队方法永远返回true，所以不要通过返回值判断入队是否成功。
出队，删除元素的操作
出队列的就是从队列里返回一个节点元素，并清空该节点对元素的引用。让我们通过每个节点出队的快照来观察下head节点的变化：
如上图所示，是元素出队过程。
主要做两件事情：
第一是队列移除出队元素的Node。
第二是更新head节点。并不是每次出队时都更新head节点，当head节点里有元素时，直接弹出head节点里的元素，而不会更新head节点。只有当head节点里没有元素时，出队操作才会更新head节点。
public E poll() {
Node<E> h = head;
// p表示头节点，需要出队的节点
Node<E> p = h;
for (int hops = 0;; hops++) {
// 获取p节点的元素
E item = p.getItem();
// 如果p节点的元素不为空，使用CAS设置p节点引用的元素为null,如果成功则返回p节点的元素。
if (item != null && p.casItem(item, null)) {
if (hops >= HOPS) {
//将p节点下一个节点设置成head节点
Node<E> q = p.getNext();
updateHead(h, (q != null) ? q : p);
}
return item;
}
// 如果头节点的元素为空或头节点发生了变化，这说明头节点已经被另外一个线程修改了。那么获取p节点的下一个节点
Node<> next = succ(p);
// 如果p的下一个节点也为空，说明这个队列已经空了
if (next == null) {
// 更新头节点。
updateHead(h, p);
break;
}
// 如果下一个元素不为空，则将头节点的下一个节点设置成头节点
p = next;
}
return null;
}
// 更新head节点的updateHead方法：
final void updateHead(Node<E> h, Node<E> p)
{
// 如果两个结点不相同，尝试用CAS指令原子更新head指向新头节点
if (h != p && casHead(h, p))
//将旧的头结点指向自身以实现删除
h.lazySetNext(h);
}
首先获取head节点的元素，并判断head节点元素是否为空，如果为空，表示另外一个线程已经进行了一次出队操作将该节点的元素取走，如果不为空，则使用CAS的方式将head节点的引用设置成null，如果CAS成功，则直接返回head节点的元素，如果CAS不成功，表示另外一个线程已经进行了一次出队操作更新了head节点，导致元素发生了变化，需要重新获取head节点。如果p节点的下一个节点为null，则说明这个队列为空（此时队列没有元素，只有一个伪结点p），则更新head节点。
判断队列是否为空
有些人在判断队列是否为空时喜欢用queue.size()==0，让我们来看看size方法：
public int size()
{
int count = 0;
for (Node<E> p = first(); p != null; p = succ(p))
if (p.item != null)
// Collection.size() spec says to max out
if (++count == Integer.MAX_VALUE)
break;
return count;
}
可以看到这样在队列在结点较多时会依次遍历所有结点，这样的性能会有较大影响，因而可以考虑empty函数，它只要判断第一个结点(注意不一定是head指向的结点)。
public boolean isEmpty() {
return first() == null;
}
通过对offer和poll方法的分析，我们发现tail和head是延迟更新的，两者更新触发时机为：
tail更新触发时机：当tail指向的节点的下一个节点不为null的时候，会执行定位队列真正的队尾节点的操作，找到队尾节点后完成插入之后才会通过casTail进行tail更新；当tail指向的节点的下一个节点为null的时候，只插入节点不更新tail。
head更新触发时机：当head指向的节点的item域为null的时候，会执行定位队列真正的队头节点的操作，找到队头节点后完成删除之后才会通过updateHead进行head更新；当head指向的节点的item域不为null的时候，只删除节点不更新head。
那么这样设计的意图是什么呢?
如果让tail永远作为队列的队尾节点，实现的代码量会更少，而且逻辑更易懂。但是，这样做有一个缺点，如果大量的入队操作，每次都要执行CAS进行tail的更新，汇总起来对性能也会是大大的损耗。如果能减少CAS更新的操作，无疑可以大大提升入队的操作效率，所以doug lea大师每间隔1次(tail和队尾节点的距离为1)进行才利用CAS更新tail。对head的更新也是同样的道理，虽然这样设计会多出在循环中定位队尾节点，但总体来说读的操作效率要远远高于写的性能，因此，多出来的在循环中定位尾节点的操作的性能损耗相对而言是很小的。
ConcurrentLinkedQueue通过无锁来做到了更高的并发量，是个高性能的队列，但是使用场景相对不如阻塞队列常见，毕竟取数据也要不停的去循环，不如阻塞的逻辑好设计，但是在并发量特别大的情况下，是个不错的选择，性能上好很多，而且这个队列的设计也是特别费力，尤其的使用的改良算法和对哨兵的处理。整体的思路都是比较严谨的，这个也是使用了无锁造成的，我们自己使用无锁的条件的话，这个队列是个不错的参考。
BlockingQueue通常用于一个线程生产对象，而另外一个线程消费这些对象的场景。
下图是对这个原理的阐述：
队列有容纳的临界点。也就是说，它是有限的。
负责生产的线程将会一直往队列里边插入新对象，如果生产线程尝试将对象放入队列时，该队列已经到达临界点，这个生产线程会一直处于阻塞之中，直到负责消费的线程从队列中拿走一个对象。
负责消费的线程将会一直从该阻塞队列中拿出对象，如果消费线程尝试去从一个空的队列中提取对象的话，这个消费线程将会处于阻塞之中，直到一个生产线程把一个对象丢进队列。
这里是一个Java中使用BlockingQueue的示例。
本示例使用的是BlockingQueue接口的ArrayBlockingQueue实现。
1、Producer 类
注意它在每次put()调用时是如何休眠一秒钟的。这将导致Consumer在等待队列中对象的时候发生阻塞。
public class Producer implements Runnable{
protected BlockingQueue queue = null;
public Producer(BlockingQueue queue) {
this.queue = queue;
}
public void run() {
try {
queue.put("1");
Thread.sleep(1000);
queue.put("2");
Thread.sleep(1000);
queue.put("3");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
2、Consumer类
它只是把对象从队列中抽取出来，然后将它们打印到System.out
public class Consumer implements Runnable{
protected BlockingQueue queue = null;
public Consumer(BlockingQueue queue) {
this.queue = queue;
}
public void run() {
try {
System.out.println(queue.take());
System.out.println(queue.take());
System.out.println(queue.take());
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
3、BlockingQueueExample
分别在两个独立的线程中启动了一个Producer和一个Consumer。
public class BlockingQueueExample {
public static void main(String[] args) throws Exception {
BlockingQueue queue = new ArrayBlockingQueue(1024);
Producer producer = new Producer(queue);
Consumer consumer = new Consumer(queue);
new Thread(producer).start();
new Thread(consumer).start();
Thread.sleep(4000);
}
}
BlockingDeque类是一个双端队列，在不能够插入元素时，它将阻塞住试图插入元素的线程；在不能够抽取元素时，它将阻塞住试图抽取的线程。
deque(双端队列)是"Double Ended Queue"的缩写。因此，双端队列是一个你可以从任意一端插入或者抽取元素的队列。当线程既是一个队列的生产者又是这个队列的消费者的时候可以使用到BlockingDeque。如果生产者线程需要在队列的两端都可以插入数据，消费者线程需要在队列的两端都可以移除数据，这个时候也可以使用BlockingDeque。
BlockingDeque 图解：
java.util.concurrent包提供了以下BlockingDeque接口的实现类：LinkedBlockingDeque
BlockingDeque<String> deque = new LinkedBlockingDeque<String>();
deque.addFirst("1");
deque.addLast("2");
String two = deque.takeLast();
String one = deque.takeFirst();