不惑JAVA之JAVA基础 - Concurrent 概述

本来想写ConcurrentHashMap的，但是感觉单写这一个知识点有点烂大街。java.util.concurrent包除了ConcurrentHashMap还是有很多好东西的，下面将会对一些重点知识点进行讲述。由于本人能力有限如有解释不到位的地方请各位大神们指出。

本博文参考和引用了大量优秀博文，感谢这些优秀的博主。

java.util.concurrent 包含许多线程安全、测试良好、高性能的并发构建块。

concurrent包的实现示意图：



JDK 中的并发改进可以分为三组：

（简单了解）

- JVM 级别更改。大多数现代处理器对并发对某一硬件级别提供支持，通常以 compare-and-swap （CAS）指令形式。CAS是一种低级别的、细粒度的技术，它允许多个线程更新一个内存位置，同时能够检测其他线程的冲突并进行恢复。它是许多高性能并发算法的基础。在DK 5.0 之前，Java 语言中用于协调线程之间的访问的惟一原语是同步，同步是更重量级和粗粒度的。公开 CAS 可以开发高度可伸缩的并发 Java 类。这些更改主要由 JDK 库类使用，而不是由开发人员使用。

- 低级实用程序类 – 锁定和原子类。使用 CAS 作为并发原语，ReentrantLock 类提供与 synchronized原语相同的锁定和内存语义，然而这样可以更好地控制锁定（如计时的锁定等待、锁定轮询和可中断的锁定等待）和提供更好的可伸缩性（竞争时的高性能）。大多数开发人员将不再直接使用ReentrantLock 类，而是使用在 ReentrantLock 类上构建的高级类。

- 高级实用程序类。这些类实现并发构建块，每个计算机科学文本中都会讲述这些类信号、互斥、闩锁、屏障、交换程序、线程池和线程安全集合类等。大部分开发人员都可以在应用程序中用这些类，来替换许多（如果不是全部）同步、wait()和 notify() 的使用，从而提高性能、可读性和正确性。

从包的结构和功能角度来分，分为：

原子对象

并发容器

同步设备

锁

Fork-join框架

执行器和线程池

下面我们按照包结构及其功能的分类进行概要说明。

原子对象

原子对象是在不使用同步的情况下保证原子性。

CAS

在将atomic包前先来讲一下CAS。所谓CAS（Compare and Swap）翻译成比较并交换。

CAS的原理是：3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。

java.util.concurrent包中借助CAS实现了区别于synchronouse（是对象计数的原则，可以参见不惑JAVA之JAVA基础 - 锁 -synchronized、Lock解析）同步锁的一种乐观锁。

CAS的CPU级别的原理我在这就不多介绍了，这里主要讲系统级别的。

CAS缺点

CAS虽然很高效的解决原子操作，但是CAS仍然存在三大问题。ABA问题，循环时间长开销大和只能保证一个共享变量的原子操作。

ABA问题。因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A就会变成1A-2B－3A。

从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

循环时间长开销大。自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory

order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

只能保证一个共享变量的原子操作。当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

CAS在concurrent包中的实现

由于java的CAS同时具有 volatile 读和volatile写的内存语义（如果对volatile不是太了解的可以查看不惑JAVA之JAVA基础 - volatile），因此Java线程之间的通信现在有了下面四种方式：

A线程写volatile变量，随后B线程读这个volatile变量。

A线程写volatile变量，随后B线程用CAS更新这个volatile变量。

A线程用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量。

A线程用CAS更新一个volatile变量，随后B线程读这个volatile变量。

AtomicInteger

我们以AtomicInteger举例说明atomic包中类的实现原理。下面是他的核心方法：



getAndIncrement：当前值加一，返回自增前的值。此方法为原子性操作，即保证在得到当前值与自增 之间，没有任何其他更新操作。举个例子，假如是value++，两个线程同时调用此函数，两个线程都取到了当前值100，然后都基于100加一，最后得到 101，miss掉了一次自增。采用compareAndSet，两个线程同时取到当前值100，线程一成功调用compareAndSet，当前值变为 101，返回；线程二调用compareAndSet失败，回到循环头，重新取得一个新的当前值101，接着成功调用comareAndSet，更新当前 值为102，返回。

public final int getAndIncrement() {
for (;;) { // 不停尝试，直到成功
int current = get(); // 获取当前值，由于get过去的值是volatile类型，可以获得当前最新值
int next = current + 1;
if (compareAndSet(current, next))
// 如果当前值未受其他线程影响，则设置新值
return current;
}
}

这里来看一下for(;;)，很有意思吧。其实就相当于

while(true) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return current;
}

再开看一下compareAndSet，compareAndSet说的是如果当前值与期望值(第一个参数)相等，则设置为新值(第二个参数)，设置成功返回true。

public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

public native boolean compareAndSwapInt(Object obj, long offset,int expect, int update);

下面就没有代码了，有兴趣可以看看java Atomic 包实现。大体里面功能是：加上LOCK前缀，保证原子性；添加Volatile避免编译器优化，打乱顺序(reorder)。

并发容器

这部分并发容器可以分为这么几类：

阻塞队列

类名	简介
BlockingQueue.class，	阻塞队列接口
BlockingDeque.class，	双端阻塞队列接口
ArrayBlockingQueue.class，	阻塞队列，数组实现
LinkedBlockingDeque.class，	阻塞双端队列，链表实现
LinkedBlockingQueue.class，	阻塞队列，链表实现
DelayQueue.class，	阻塞队列，并且元素是Delay的子类，保证元素在达到一定时间后才可以取得到
PriorityBlockingQueue.class，	优先级阻塞队列
SynchronousQueue.class，	同步队列，但是队列长度为0，生产者放入队列的操作会被阻塞，直到消费者过来取，所以这个队列根本不需要空间存放元素；有点像一个独木桥，一次只能一人通过，还不能在桥上停留

阻塞队列就不多讲有兴趣的可以参见不惑JAVA之JAVA基础 - 阻塞队列。值得注意的是Queue接口本身定义的几个常用方法的区别，

add方法和offer方法的区别在于超出容量限制时前者抛出异常，后者返回false；

remove方法和poll方法都从队列中拿掉元素并返回，但是他们的区别在于空队列下操作前者抛出异常，而后者返回null；

element方法和peek方法都返回队列顶端的元素，但是不把元素从队列中删掉，区别在于前者在空队列的时候抛出异常，后者返回null。

非阻塞队列：

类名	简介
ConcurrentLinkedDeque.class，	非阻塞双端队列，链表实现
ConcurrentLinkedQueue.class，	非阻塞队列，链表实现

转移队列：

类名	简介
TransferQueue.class，	转移队列接口，生产者要等消费者消费的队列，生产者尝试把元素直接转移给消费者
LinkedTransferQueue.class，	转移队列的链表实现，它比SynchronousQueue更快

其它容器：

类名	简介
ConcurrentMap.class，	并发Map的接口，定义了putIfAbsent(k,v)、remove(k,v)、replace(k,oldV,newV)、replace(k,v)这四个并发场景下特定的方法
ConcurrentHashMap.class，	并发HashMap
ConcurrentNavigableMap.class，	NavigableMap的实现类，返回最接近的一个元素
ConcurrentSkipListSet.class，	和上面类似，只不过map变成了set
CopyOnWriteArrayList.class，	copy-on-write模式的arrayList，每当需要插入元素，不在原list上操作，而是会新建立一个list，适合读远远大于写并且写时间并苛刻的场景
CopyOnWriteArraySet.class，	和上面类似，list变成set而已

下面会对比较常用的ConcurrentHashMap和CopyOnWriteArrayList进行讲解。

ConcurrentHashMap

如果对HashMap还是不是太了解的话，可以参考不惑JAVA之JAVA基础 - HashMap。

ConcurrentHashMap的锁分段技术

HashTable容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有访问HashTable的线程都必须竞争同一把锁，那假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。

ConcurrentHashMap的内部结构

上面说的是不是比较难以理解是不是，没关系向下看。我们来了解一下ConcurrentHashMap内部结构就会慢慢明白。

ConcurrentHashMap为了提高本身的并发能力，在内部采用了一个叫做Segment的结构，一个Segment其实就是一个类Hash Table的结构，Segment内部维护了一个链表数组，我们用下面这一幅图来看下ConcurrentHashMap的内部结构：



从上面的结构我们可以了解到，ConcurrentHashMap定位一个元素的过程需要进行两次Hash操作，第一次Hash定位到Segment，第二次Hash定位到元素所在的链表的头部，因此，这一种结构的带来的副作用是Hash的过程要比普通的HashMap要长，但是带来的好处是写操作的时候可以只对元素所在的Segment进行加锁即可，不会影响到其他的Segment，这样，在最理想的情况下，ConcurrentHashMap可以最高同时支持Segment数量大小的写操作（刚好这些写操作都非常平均地分布在所有的Segment上），所以，通过这一种结构，ConcurrentHashMap的并发能力可以大大的提高。

Segment

static final class Segment<K,V> extends ReentrantLock implements Serializable {
transient volatile int count;
transient int modCount;
transient int threshold;
transient volatile HashEntry<K,V>[] table;
final float loadFactor;
}

count：Segment中元素的数量

modCount：对table的大小造成影响的操作的数量（比如put或者remove操作）

threshold：阈值，Segment里面元素的数量超过这个值依旧就会对Segment进行扩容

table：链表数组，数组中的每一个元素代表了一个链表的头部

loadFactor：负载因子，用于确定threshold

Segment继承了ReentrantLock，表明每个segment都可以当做一个锁。这样对每个segment中的数据需要同步操作的话都是使用每个segment容器对象自身的锁来实现。只有对全局需要改变时锁定的是所有的segment。

HashEntry

static final class HashEntry<K,V> {
final K key;
final int hash;
volatile V value;
final HashEntry<K,V> next;
}

这个跟HashMap一样，就不多说了。

ConcurrentHashMap的初始化

public ConcurrentHashMap(int initialCapacity,
float loadFactor, int concurrencyLevel) {
if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0)
throw new IllegalArgumentException();

if (concurrencyLevel > MAX_SEGMENTS)
concurrencyLevel = MAX_SEGMENTS;

// Find power-of-two sizes best matching arguments
int sshift = 0;
int ssize = 1;
while (ssize < concurrencyLevel) {
++sshift;
ssize <<= 1;
}
segmentShift = 32 - sshift;
segmentMask = ssize - 1;
this.segments = Segment.newArray(ssize);

if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
int c = initialCapacity / ssize;
if (c * ssize < initialCapacity)
++c;
int cap = 1;
while (cap < c)
cap <<= 1;

for (int i = 0; i < this.segments.length; ++i)
this.segments[i] = new Segment<K,V>(cap, loadFactor);
}

CurrentHashMap的初始化一共有三个参数，一个initialCapacity，表示初始的容量，一个loadFactor，表示负载参数，最后一个是concurrentLevel，代表ConcurrentHashMap内部的Segment的数量，ConcurrentLevel一经指定，不可改变，后续如果ConcurrentHashMap的元素数量增加导致ConrruentHashMap需要扩容，ConcurrentHashMap不会增加Segment的数量，而只会增加Segment中链表数组的容量大小，这样的好处是扩容过程不需要对整个ConcurrentHashMap做rehash，而只需要对Segment里面的元素做一次rehash就可以了。

默认情况下initialCapacity等于16，loadfactor等于0.75，通过运算cap等于1，threshold等于零。

由上面的代码可知segments数组的长度ssize通过concurrencyLevel计算得出。为了能通过按位与的哈希算法来定位segments数组的索引，必须保证segments数组的长度是2的N次方（power-of-two size），所以必须计算出一个是大于或等于concurrencyLevel的最小的2的N次方值来作为segments数组的长度。假如concurrencyLevel等于14，15或16，ssize都会等于16，即容器里锁的个数也是16。注意concurrencyLevel的最大大小是65535，意味着segments数组的长度最大为65536，对应的二进制是16位。

初始化segmentShift和segmentMask。这两个全局变量在定位segment时的哈希算法里需要使用，sshift等于ssize从1向左移位的次数，在默认情况下concurrencyLevel等于16，1需要向左移位移动4次，所以sshift等于4。segmentShift用于定位参与hash运算的位数，segmentShift等于32减sshift，所以等于28，这里之所以用32是因为ConcurrentHashMap里的hash()方法输出的最大数是32位的，后面的测试中我们可以看到这点。segmentMask是哈希运算的掩码，等于ssize减1，即15，掩码的二进制各个位的值都是1。因为ssize的最大长度是65536，所以segmentShift最大值是16，segmentMask最大值是65535，对应的二进制是16位，每个位都是1。

ConcurrentHashMap的get操作

get操作是不用加锁的，主要通过volatile来保证。

public V get(Object key) {
// 获得key的hash位置
int hash = hash(key.hashCode());
// segmentFor用于确定操作应该在哪一个segment中进行
return segmentFor(hash).get(key, hash);
}

final Segment<K,V> segmentFor(int hash) {
return segments[(hash >>> segmentShift) & segmentMask];
}

用了位操作来确定Segment，根据传入的hash值向右无符号右移segmentShift位，然后和segmentMask进行与操作，结合我们之前说的segmentShift和segmentMask的值，就可以得出以下结论：假设Segment的数量是2的n次方，根据元素的hash值的高n位就可以确定元素到底在哪一个Segment中。

V get(Object key, int hash) {
if (count != 0) { // read-volatile
HashEntry<K,V> e = getFirst(hash);
while (e != null) {
if (e.hash == hash && key.equals(e.key)) {
V v = e.value;
if (v != null)
return v;
return readValueUnderLock(e); // recheck
}
e = e.next;
}
}
return null;
}

get才是核心代码，具体是这样的：

先判断一下 count !=0；count变量表示segment中存在entry的个数。如果为0就不用找了。由于count是volatile修饰，所以，每次判断count变量的时候，即使恰好其他线程改变了segment也会体现出来。

在确定了链表的头部以后，就可以对整个链表进行遍历，看第4行，取出key对应的value的值，如果拿出的value的值是null，则可能这个key，value对正在put的过程中，如果出现这种情况，那么就加锁来保证取出的value是完整的，如果不是null，则直接返回value。

ConcurrentHashMap的put操作

V put(K key, int hash, V value, boolean onlyIfAbsent) {
lock();
try {
int c = count;
if (c++ > threshold) // ensure capacity
rehash();
HashEntry<K,V>[] tab = table;
int index = hash & (tab.length - 1);
HashEntry<K,V> first = tab[index];
HashEntry<K,V> e = first;
while (e != null && (e.hash != hash || !key.equals(e.key)))
e = e.next;

V oldValue;
if (e != null) {
oldValue = e.value;
if (!onlyIfAbsent)
e.value = value;
}
else {
oldValue = null;
++modCount;
tab[index] = new HashEntry<K,V>(key, hash, first, value);
count = c; // write-volatile
}
return oldValue;
} finally {
unlock();
}
}

首先对Segment的put操作是加锁完成的，然后在第五行，如果Segment中元素的数量超过了阈值（由构造函数中的loadFactor算出）这需要进行对Segment扩容，并且要进行rehash。rehash在HashMap已经讲述这里就不在说明了；

第8和第9行的操作就是getFirst的过程，确定链表头部的位置；

第11行这里的这个while循环是在链表中寻找和要put的元素相同key的元素，如果找到，就直接更新更新key的value，如果没有找到，则进入21行这里，生成一个新的HashEntry并且把它加到整个Segment的头部，然后再更新count的值。

ConcurrentHashMap的remove操作

V remove(Object key, int hash, Object value) {
lock();
try {
int c = count - 1;
HashEntry<K,V>[] tab = table;
int index = hash & (tab.length - 1);
HashEntry<K,V> first = tab[index];
HashEntry<K,V> e = first;
while (e != null && (e.hash != hash || !key.equals(e.key)))
e = e.next;

V oldValue = null;
if (e != null) {
V v = e.value;
if (value == null || value.equals(v)) {
oldValue = v;
// All entries following removed node can stay
// in list, but all preceding ones need to be
// cloned.
++modCount;
HashEntry<K,V> newFirst = e.next;
for (HashEntry<K,V> p = first; p != e; p = p.next)
newFirst = new HashEntry<K,V>(p.key, p.hash,
newFirst, p.value);
tab[index] = newFirst;
count = c; // write-volatile
}
}
return oldValue;
} finally {
unlock();
}
}

整个操作是在持有段锁的情况下执行的，空白行之前的行主要是定位到要删除的节点e。接下来，如果不存在这个节点就直接返回null，否则就要将e前面的结点复制一遍，尾结点指向e的下一个结点。e后面的结点不需要复制，它们可以重用。

中间那个for循环是做什么用的呢？从代码来看，就是将定位之后的所有entry克隆并拼回前面去，但有必要吗？每次删除一个元素就要将那之前的元素克隆一遍？这点其实是由entry的不变性来决定的，仔细观察entry定义，发现除了value，其他所有属性都是用final来修饰的，这意味着在第一次设置了next域之后便不能再改变它，取而代之的是将它之前的节点全都克隆一次。至于entry为什么要设置为不变性，这跟不变性的访问不需要同步从而节省时间有关。

示意图：

删除元素之前：



删除元素3之后：



第二个图其实有点问题，复制的结点中应该是值为2的结点在前面，值为1的结点在后面，也就是刚好和原来结点顺序相反，还好这不影响我们的讨论。

整个remove实现并不复杂，但是需要注意如下几点。

当要删除的结点存在时，删除的最后一步操作要将count的值减一。这必须是最后一步操作，否则读取操作可能看不到之前对段所做的结构性修改。

remove执行的开始就将table赋给一个局部变量tab，这是因为table是volatile变量，读写volatile变量的开销很大。编译器也不能对volatile变量的读写做任何优化，直接多次访问非volatile实例变量没有多大影响，编译器会做相应优化。

ConcurrentHashMap的size操作

ConcurrentHashMap的size操作采用了一种比较巧的方式，来尽量避免对所有的Segment都加锁。

　　一个Segment中的有一个modCount变量，代表的是对Segment中元素的数量造成影响的操作的次数，这个值只增不减，size操作就是遍历了两次Segment，每次记录Segment的modCount值，然后将两次的modCount进行比较，如果相同，则表示期间没有发生过写入操作，就将原先遍历的结果返回，如果不相同，则把这个过程再重复做一次，如果再不相同，则就需要将所有的Segment都锁住，然后一个一个遍历了。

　　

CopyOnWriteArrayList

Copy-On-Write简称COW，是一种用于程序设计中的优化策略。其基本思路是，从一开始大家都在共享同一个内容，当某个人想要修改这个内容的时候，才会真正把内容Copy出去形成一个新的内容然后再改，这是一种延时懒惰策略。从JDK1.5开始Java并发包里提供了两个使用CopyOnWrite机制实现的并发容器,它们是CopyOnWriteArrayList和CopyOnWriteArraySet。CopyOnWrite容器非常有用，可以在非常多的并发场景中使用到。

CopyOnWrite容器设计思路

CopyOnWrite容器即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。

CopyOnWriteArrayList的实现原理

在使用CopyOnWriteArrayList之前，我们先阅读其源码了解下它是如何实现的。以下代码是向CopyOnWriteArrayList中add方法的实现（向CopyOnWriteArrayList里添加元素），可以发现在添加的时候是需要加锁的，否则多线程写的时候会Copy出N个副本出来。

public boolean add(E e) {
final ReentrantLock lock = this.lock;
lock.lock();
try {
Object[] elements = getArray();
int len = elements.length;
Object[] newElements = Arrays.copyOf(elements, len + 1);
newElements[len] = e;
setArray(newElements);
return true;
} finally {
lock.unlock();
}
}

读的时候不需要加锁，如果读的时候有多个线程正在向CopyOnWriteArrayList添加数据，读还是会读到旧的数据，因为写的时候不会锁住旧的CopyOnWriteArrayList。

public E get(int index) {
return get(getArray(), index);
}

CopyOnWrite机制

JDK中并没有提供CopyOnWriteMap，我们可以参考CopyOnWriteArrayList来实现一个，基本代码如下：

import java.util.Collection;
import java.util.Map;
import java.util.Set;

public class CopyOnWriteMap<K, V> implements Map<K, V>, Cloneable {
private volatile Map<K, V> internalMap;

public CopyOnWriteMap() {
internalMap = new HashMap<K, V>();
}

public V put(K key, V value) {

synchronized (this) {
Map<K, V> newMap = new HashMap<K, V>(internalMap);
V val = newMap.put(key, value);
internalMap = newMap;
return val;
}
}

public V get(Object key) {
return internalMap.get(key);
}

public void putAll(Map<? extends K, ? extends V> newData) {
synchronized (this) {
Map<K, V> newMap = new HashMap<K, V>(internalMap);
newMap.putAll(newData);
internalMap = newMap;
}
}
}

实现很简单，只要了解了CopyOnWrite机制，我们可以实现各种CopyOnWrite容器，并且在不同的应用场景中使用。

CopyOnWrite的应用场景

CopyOnWrite并发容器用于读多写少的并发场景。比如白名单，黑名单，商品类目的访问和更新场景，假如我们有一个搜索网站，用户在这个网站的搜索框中，输入关键字搜索内容，但是某些关键字不允许被搜索。这些不能被搜索的关键字会被放在一个黑名单当中，黑名单每天晚上更新一次。当用户搜索时，会检查当前关键字在不在黑名单当中，如果在，则提示不能搜索。

CopyOnWrite的缺点

CopyOnWrite容器有很多优点，但是同时也存在两个问题，即内存占用问题和数据一致性问题。

　内存占用问题。因为CopyOnWrite的写时复制机制，所以在进行写操作的时候，内存里会同时驻扎两个对象的内存，旧的对象和新写入的对象

数据一致性问题。CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。

锁

可以参见我之前的写的博文不惑JAVA之JAVA基础 - 锁 -synchronized、Lock解析

线程池

这个知识点之前已经写过了，可以参考不惑JAVA之JAVA基础 - 线程池。

参考：

java.util.concurrent介绍

JAVA CAS原理深度分析

ABA问题参考文档

聊聊并发（四）深入分析ConcurrentHashMap

Java并发编程：并发容器之ConcurrentHashMap（转载）

Java并发编程：并发容器之CopyOnWriteArrayList（转载）