在上一篇文章【简单了解系列】从基础的使用来深挖HashMap里，我从最基础的使用中介绍了HashMap，大致是JDK1.7和1.8中底层实现的变化，和介绍了为什么在多线程下可能会造成死循环，扩容机制是什么样的。感兴趣的可以先看看。
我们知道，HashMap是非线程安全的容器，那么为什么ConcurrentHashMap能够做到线程安全呢？
首先看一下ConcurrentHashMap的底层数据结构，在Java8中，其底层的实现方式与HashMap一样的，同样是数组、链表再加红黑树，具体的可以参考上面的HashMap的文章，下面所有的讨论都是基于Java 1.8。
transient volatile Node<K,V>[] table;
对比HashMap的底层结构可以发现，table的定义中多了一个volatile关键字。这个关键字是做什么的呢？我们知道所有的共享变量都存在主内存中，就像table。
而线程对变量的所有操作都必须在线程自己的工作内存中完成，而不能直接读取主存中的变量，这是JMM的规定。所以每个线程都会有自己的工作内存，工作内存中存放了共享变量的副本。而正是因为这样，才造成了可见性的问题。
ABCD四个线程同时在操作一个共享变量X，此时如果A从主存中读取了X，改变了值，并且写回了内存。那么BCD线程所得到的X副本就已经失效了。此时如果没有被volatile修饰，那么BCD线程是不知道自己的变量副本已经失效了。继续使用这个变量就会造成数据不一致的问题。
而如果加上了volatile关键字，BCD线程就会立马看到最新的值，这就是内存可见性。你可能想问，凭什么加了volatile的关键字就可以保证共享变量的内存可见性？
那是因为如果变量被volatile修饰，在线程进行写操作时，会直接将新的值写入到主存中，而不是线程的工作内存中；而在读操作时，会直接从主存中读取，而不是线程的工作内存。
首先这个使用与HashMap没有任何区别，只是实现改成了ConcurrentHashMap。
Map<String, String> map = new ConcurrentHashMap<>();
map.put("微信搜索", "SH的全栈笔记");
map.get("微信搜索"); // SH的全栈笔记
首先我们来看一下get方法的使用，源码如下。
public V get(Object key) {
Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
int h = spread(key.hashCode());
if ((tab = table) != null && (n = tab.length) > 0 &&
(e = tabAt(tab, (n - 1) & h)) != null) {
if ((eh = e.hash) == h) {
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
}
else if (eh < 0)
return (p = e.find(h, key)) != null ? p.val : null;
while ((e = e.next) != null) {
if (e.hash == h &&
((ek = e.key) == key || (ek != null && key.equals(ek))))
return e.val;
}
}
return null;
}
大概解释一下这个过程发生了什么，首先根据key计算出哈希值，如果找到了就直接返回值。如果是红黑树的话，就在红黑树中查找值，否则就按照链表的查找方式查找。
这与HashMap也差不多的，元素会首先以链表的方式进行存储，如果该桶中的元素数量大于TREEIFY_THRESHOLD的值，就会触发树化。将当前的链表转换为红黑树。因为如果数量太多的话，链表的查询效率就会变得非常低，时间复杂度为O(n)，而红黑树的查询时间复杂度则为O(logn)，这个阈值在Java 1.8中的默认值为8，定义如下。
static final int TREEIFY_THRESHOLD = 8;
put的源码就不放出来了，放在这大家估计也不会一行一行的去看。所以我就简单的解释一下put的过程发生了什么事，并贴上关键代码就好了。
整个过程，除开并发的一些细节，大致的流程和1.8中的HashMap是差不多的。
看到这你可能会有一堆的疑问。
例如在多线程的情况下，几个线程同时来执行put操作时，怎么保证只执行一次初始化，或者怎么保证只执行一次扩容呢？万一我已经写入了数据，另一个线程又初始化了一遍，岂不是造成了数据不一致的问题。同样是多线程的情况下， 怎么保证put值的时候不会被其他线程覆盖。CAS又是什么？
接下来我们就来看一下在多线程的情况下，ConcurrentHashMap是如何保证线程安全的。
首先我们来看初始化的源码。
private final Node<K,V>[] initTable() {
Node<K,V>[] tab; int sc;
while ((tab = table) == null || tab.length == 0) {
if ((sc = sizeCtl) < 0)
Thread.yield(); // lost initialization race; just spin
else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) {
try {
if ((tab = table) == null || tab.length == 0) {
int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
@SuppressWarnings("unchecked")
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];
table = tab = nt;
sc = n - (n >>> 2);
}
} finally {
sizeCtl = sc;
}
break;
}
}
return tab;
}
可以看到有一个关键的变量，sizeCtl，其定义如下。
private transient volatile int sizeCtl;
sizeCtl使用了关键字volatile修饰，说明这是一个多线程的共享变量，可以看到如果是首次初始化，第一个判断条件if ((sc = sizeCtl) < 0)是不会满足的，正常初始化的话sizeCtl的值为0，初始化设定了size的话sizeCtl的值会等于传入的size，而这两个值始终是大于0的。
然后就会进入下面的U.compareAndSwapInt(this, SIZECTL, sc, -1)方法，这就是上面提到的CAS，Compare and Swap（Set），比较并交换，Unsafe是位于sun.misc下的一个类，在Java底层用的比较多，它让Java拥有了类似C语言一样直接操作内存空间的能力。
例如可以操作内存、CAS、内存屏障、线程调度等等，但是如果Unsafe类不能被正确使用，就会使程序变的不安全，所以不建议程序直接使用它。
compareAndSwapInt的四个参数分别是，实例、偏移地址、预期值、新值。偏移地址可以快速帮我们在实例中定位到我们要修改的字段，此例中便是sizeCtl。如果内存当中的sizeCtl是传入的预期值，则将其更新为新的值。这个Unsafe类的方法可以保证这个操作的原子性。当你在使用parallelStream进行并发的foreach遍历时，如果涉及到修改一个整型的共享变量时，你肯定不能直接用i++，因为在多线程下，i++每次操作不能保证原子性。所以你可能会用到如下的方式。
AtomicInteger num = new AtomicInteger();
arr.parallelStream().forEach(item -> num.getAndIncrement());
你可能会好奇，为什么使用了AtomicInteger就可以保证原子性，跟Unsafe类和CAS又有什么关系，让我们接着往下，看getAndIncrement方法的底层实现。
public final int getAndIncrement() {
return unsafe.getAndAddInt(this, valueOffset, 1);
}
可以看到，底层调用的是Unsafe类的方法，这不就联系上了吗，而getAndIncrement的实现又长这样。
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
没错，这里底层调用了compareAndSwapInt方法。可以看到这里加了while，如果该方法返回false就一直循环，直到成功为止。这个过程有个
