原文链接：https://blog.csdn.net/artaganan8/article/details/80867158
ConcurrentHashMap是Java5中新增加的一个线程安全的Map集合，可以用来替代HashTable。对于ConcurrentHashMap是如何提高其效率的，可能大多人只是知道它使用了多个锁代替HashTable中的单个锁，也就是锁分离技术（Lock Stripping）。实际上，ConcurrentHashMap对提高并发方面的优化，还有一些其它的技巧在里面（比如你是否知道在get操作的时候，它是否也使用了锁来保护？）。
ConcurrentMap
提供其他原子 putIfAbsent、remove、replace 方法的 Map。 内存一致性效果：当存在其他并发 collection 时，将对象放入 ConcurrentMap 之前的线程中的操作 happen-before 随后通过另一线程从 ConcurrentMap 中访问或移除该元素的操作。
我们不关心ConcurrentMap中新增的接口，重点理解一下内存一致性效果中的“happens-before”是怎么回事。因为要想从根本上讲明白，这个是无法避开的。这又不得不从Java存储模型来谈起了。
理解JAVA存储模型(JMM)的Happens-Before规则
在解释该规则之前，我们先看一段多线程访问数据的代码例子：
public class Test1 {
private int a=1, b=2;
public void foo(){ // 线程1
a=3;
b=4;
}
public int getA(){ // 线程2
return a;
}
public int getB(){ // 线程2
return b;
}
}
上面的代码，当线程1执行foo方法的时候，线程2访问getA和getB会得到什么样的结果？
答案：
A：a=1, b=2 // 都未改变 B：a=3, b=4 // 都改变了 C：a=3, b=2 // a改变了，b未改变 D：a=1, b=4 // b改变了，a未改变
上面的A,B,C都好理解，但是D可能会出乎一些人的预料。
一些不了解JMM的同学可能会问怎么可能 b=4语句会先于 a=3 执行？
这是一个多线程之间内存可见性（Visibility）顺序不一致的问题。有两种可能会造成上面的D选项。
1) Java编译器的重排序(Reording)操作有可能导致执行顺序和代码顺序不一致。
关于Reording：
Java语言规范规定了JVM要维护内部线程类似顺序化语义(within-thread as-is-serial semantics)：只要程序的最终结果等同于它在严格的顺序化环境中执行的结果，那么上述所有的行为都是允许的。
上面的话是《Java并发编程实践》一书中引自Java语言规范的，感觉翻译的不太好。简单的说：假设代码有两条语句，代码顺序是语句1先于语句2执行；那么只要语句2不依赖于语句1的结果，打乱它们的顺序对最终的结果没有影响的话，那么真正交给CPU去执行时，他们的顺序可以是没有限制的。可以允许语句2先于语句1被CPU执行，和代码中的顺序不一致。
重排序（Reordering）是JVM针对现代CPU的一种优化，Reordering后的指令会在性能上有很大提升。(不知道这种优化对于多核CPU是否更加明显，也或许和单核多核没有关系。)
因为我们例子中的两条赋值语句，并没有依赖关系，无论谁先谁后结果都是一样的，所以就可能有Reordering的情况，这种情况下，对于其他线程来说就可能造成了可见性顺序不一致的问题。
2) 从线程工作内存写回主存时顺序无法保证。
下图描述了JVM中主存和线程工作内存之间的交互：
JLS中对线程和主存互操作定义了6个行为，分别为load，save，read，write，assign和use，这些操作行为具有原子性，且相互依赖，有明确的调用先后顺序。这个细节也比较繁琐，我们暂不深入追究。先简单认为线程在修改一个变量时，先拷贝入线程工作内存中，在线程工作内存修改后再写回主存(Main Memery)中。
假设例子中Reording后顺序仍与代码中的顺序一致，那么接下来呢？有意思的事情就发生在线程把Working Copy Memery中的变量写回Main Memery的时刻。线程1把变量写回Main Memery的过程对线程2的可见性顺序也是无法保证的。
上面的列子，a=3; b=4; 这两个语句在 Working Copy Memery中执行后，写回主存的过程对于线程2来说同样可能出现先b=4；后a=3；这样的相反顺序。
正因为上面的那些问题，JMM中一个重要问题就是：如何让多线程之间，对象的状态对于各线程的“可视性”是顺序一致的。它的解决方式就是 Happens-before 规则：
JMM为所有程序内部动作定义了一个偏序关系，叫做happens-before。要想保证执行动作B的线程看到动作A的结果（无论A和B是否发生在同一个线程中），A和B之间就必须满足happens-before关系。
我们现在来看一下“Happens-before”规则都有哪些（摘自《Java并发编程实践》）：
① 程序次序法则：线程中的每个动作A都happens-before于该线程中的每一个动作B，其中，在程序中，所有的动作B都能出现在A之后。 ② 监视器锁法则：对一个监视器锁的解锁 happens-before于每一个后续对同一监视器锁的加锁。 ③ volatile变量法则：对volatile域的写入操作happens-before于每一个后续对同一个域的读写操作。 ④ 线程启动法则：在一个线程里，对Thread.start的调用会happens-before于每个启动线程的动作。 ⑤ 线程终结法则：线程中的任何动作都happens-before于其他线程检测到这个线程已经终结、或者从Thread.join调用中成功返回，或Thread.isAlive返回false。 ⑥ 中断法则：一个线程调用另一个线程的interrupt happens-before于被中断的线程发现中断。 ⑦ 终结法则：一个对象的构造函数的结束happens-before于这个对象finalizer的开始。 ⑧ 传递性：如果A happens-before于B，且B happens-before于C，则A happens-before于C
我们重点关注的是②，③，这两条也是我们通常编程中常用的。
后续分析ConcurrenHashMap时也会看到使用到锁(ReentrantLock)，Volatile，final等手段来保证happens-before规则的。
使用锁方式实现“Happens-before”是最简单，容易理解的。
早期Java中的锁只有最基本的synchronized，它是一种互斥的实现方式。在Java5之后，增加了一些其它锁，比如ReentrantLock，它基本作用和synchronized相似，但提供了更多的操作方式，比如在获取锁时不必像synchronized那样只是傻等，可以设置定时，轮询，或者中断，这些方法使得它在获取多个锁的情况可以避免死锁操作。
而我们需要了解的是ReentrantLock的性能相对synchronized来说有很大的提高。（不过据说Java6后对synchronized进行了优化，两者已经接近了。）在ConcurrentHashMap中，每个hash区间使用的锁正是ReentrantLock。
Volatile可以看做一种轻量级的锁，但又和锁有些不同。
a) 它对于多线程，不是一种互斥（mutex）关系。
b) 用volatile修饰的变量，不能保证该变量状态的改变对于其他线程来说是一种“原子化操作”。
在Java5之前，JMM对Volatile的定义是：保证读写volatile都直接发生在main memory中，线程的working memory不进行缓存。它只承诺了读和写过程的可见性，并没有对Reording做限制，所以旧的Volatile并不太可靠。在Java5之后，JMM对volatile的语义进行了增强。就是我们看到的③ volatile变量法则。
我们给contextReady 增加volatile修饰符，会带来什么效果呢？
context = loadContext() 和屏障下方的volatile写入语句 contextReady = true 无法交换顺序，从而成功阻止了指令重排序。
那对于“原子化操作”怎么理解呢？看下面例子：
private static volatile int nextSerialNum = 0;
public static int generateSerialNumber(){
return nextSerialNum++;
}
上面代码中对nextSerialNum使用了volatile来修饰，根据前面“Happens-Before”法则的第三条Volatile变量法则，看似不同线程都会得到一个新的serialNumber
问题出在了 nextSerialNum++ 这条语句上，它不是一个原子化的，实际上是read-modify-write三项操作，这就有可能使得在线程1在write之前，线程2也访问到了nextSerialNum，造成了线程1和线程2得到一样的serialNumber。
所以，在使用Volatile时，需要注意
a) 需不需要互斥；
b) 对象状态的改变是不是原子化的。
最后也说一下final 关键字。
不变模式（immutable）是多线程安全里最简单的一种保障方式。因为你拿他没有办法，想改变它也没有机会。
不变模式主要通过final关键字来限定的。在JMM中final关键字还有特殊的语义。Final域使得确保初始化安全性（initialization safety）成为可能，初始化安全性让不可变形对象不需要同步就能自由地被访问和共享。
3）经过前面的了解，下面我们用Happens-Before规则理解一个经典问题：双重检测锁(DCL)为什么在java中不适用？
public class LazySingleton {
private int someField;
private static LazySingleton instance;
private LazySingleton(){
this.someField = new Random().nextInt(200) + 1; // (1)
}
public static LazySingleton getInstance() {
if (instance == null) {// (2)
synchronized (LazySingleton.class) { // (3)
if (instance == null) { // (4)
instance = new LazySingleton(); // (5)
}
}
}
return instance; // (6)
}
public int getSomeField() {
return this.someField; // (7)
}
}
我想简单的用对象创建期间的实际场景来分析一下：（注意，这种场景是我个人的理解，所看的资料也是非官方的，不完全保证正确。如果发现不对请指出。
假设线程1执行完(5)时，线程2正好执行到了(2)；
看看 new LazySingleton(); 这个语句的执行过程： 它不是一个原子操作，实际是由多个步骤，我们从我们关注的角度简化一下，简单的认为它主要有2步操作好了：
a） 在内存中分配空间，并将引用指向该内存空间。
b） 执行对象的初始化的逻辑(和操作)，完成对象的构建。
此时因为线程1和线程2没有用同步，他们之间不存在“Happens-Before”规则的约束，所以在线程1创建LazySingleton对象的 a),b)这两个步骤对于线程2来说会有可能出现a)可见，b)不可见
造成了线程2获取到了一个未创建完整的lazySingleton对象引用，为后边埋下隐患。
之所以这里举到 DCL这个例子，是因为我们后边分析ConcurrentHashMap时，也会遇到相似的情况。
对于对象的创建，出于乐观考虑，两个线程之间没有用“Happens-Before规则来约束”另一个线程可能会得到一个未创建完整的对象，这种情况必须要检测，后续分析ConcurrentHashMap时再讨论。
ConcurrentHashMap
我们关注的操作有：get，put，remove 这3个操作。
对于哈希表，Java中采用链表的方式来解决hash冲突的。一个HashMap的数据结构看起来类似下图：
实现了同步的HashTable也是这样的结构，它的同步使用锁来保证的，并且所有同步操作使用的是同一个锁对象。这样若有n个线程同时在get时，这n个线程要串行的等待来获取锁。
ConcurrentHashMap中对这个数据结构，针对并发稍微做了一点调整。它把区间按照并发级别(concurrentLevel)，分成了若干个segment。默认情况下内部按并发级别为16来创建。对于每个segment的容量，默认情况也是16。当然并发级别(concurrentLevel)和每个段(segment)的初始容量都是可以通过构造函数设定的。
创建好默认的ConcurrentHashMap之后，它的结构大致如下图：
看起来只是把以前HashTable的一个hash bucket创建了16份而已。有什么特别的吗？没啥特别的。
继续看每个segment是怎么定义的：
static final class Segment<K,V> extends ReentrantLock implements Serializable
Segment继承了ReentrantLock，表明每个segment都可以当做一个锁。（ReentrantLock前文已经提到，不了解的话就把当做synchronized的替代者吧）这样对每个segment中的数据需要同步操作的话都是使用每个segment容器对象自身的锁来实现。只有对全局需要改变时锁定的是所有的segment。
面的这种做法，就称之为“分离锁（lock striping）”。有必要对“分拆锁”和“分离锁”的概念描述一下：
分拆锁(lock spliting)就是若原先的程序中多处逻辑都采用同一个锁，但各个逻辑之间又相互独立，就可以拆(Spliting)为使用多个锁，每个锁守护不同的逻辑。 分拆锁有时候可以被扩展，分成可大可小加锁块的集合，并且它们归属于相互独立的对象，这样的情况就是分离锁(lock striping)。（摘自《Java并发编程实践》）
看上去，单是这样就已经能大大提高多线程并发的性能了。还没完，继续看我们关注的get,put,remove这三个函数怎么保证数据同步的。
先看get方法
public V get(Object key) {
int hash = hash(key); // throws NullPointerException if key null
return segmentFor(hash).get(key, hash);
}
它没有使用同步控制，交给segment去找，再看Segment中的get方法：
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;
}
它也没有使用锁来同步，只是判断获取的entry的value是否为null，为null时才使用加锁的方式再次去获取。
这个实现很微妙，没有锁同步的话，靠什么保证同步呢？我们一步步分析。
第一步，先判断一下 count != 0；count变量表示segment中存在entry的个数。如果为0就不用找了。
假设这个时候恰好另一个线程put或者remove了这个segment中的一个entry，会不会导致两个线程看到的count值不一致呢？
看一下count变量的定义： transient volatile int count;
它使用了volatile来修改。我们前文说过，Java5之后，JMM实现了对volatile的保证：对volatile域的写入操作happens-before于每一个后续对同一个域的读写操作。
所以，每次判断count变量的时候，即使恰好其他线程改变了segment也会体现出来。
第二步，获取到要该key所在segment中的索引地址，如果该地址有相同的hash对象，顺着链表一直比较下去找到该entry。当找到entry的时候，先做了一次比较： if(v != null) 我们用红色注释的地方。
这是为何呢？
考虑一下，如果这个时候，另一个线程恰好新增/删除了entry，或者改变了entry的value，会如何？
先看一下HashEntry类结构。
static final class HashEntry<K,V> {
final K key;
final int hash;
volatile V value;
final HashEntry<K,V> next;
。。。
}
除了 value，其它成员都是final修饰的，也就是说value可以被改变，其它都不可以改变，包括指向下一个HashEntry的next也不能被改变。（那删除一个entry时怎么办？后续会讲到。）
1) 在get代码的①和②之间，另一个线程新增了一个entry
如果另一个线程新增的这个entry又恰好是我们要get的，这事儿就比较微妙了。
下图大致描述了put 一个新的entry的过程。
因为每个HashEntry中的next也是final的，没法对链表最后一个元素增加一个后续entry所以新增一个entry的实现方式只能通过头结点来插入了。
newEntry对象是通过 new HashEntry(K k , V v, HashEntry next) 来创建的。如果另一个线程刚好new 这个对象时，当前线程来get它。因为没有同步，就可能会出现当前线程得到的newEntry对象是一个没有完全构造好的对象引用。
回想一下我们之前讨论的DCL的问题，这里也一样，没有锁同步的话，new 一个对象对于多线程看到这个对象的状态是没有保障的，这里同样有可能一个线程new这个对象的时候还没有执行完构造函数就被另一个线程得到这个对象引用。
所以才需要判断一下：if (v != null) 如果确实是一个不完整的对象，则使用锁的方式再次get一次。
有没有可能会put进一个value为null的entry？ 不会的，已经做了检查，这种情况会抛出异常，所以 ②处的判断完全是出于对多线程下访问一个new出来的对象的状态检测。
2) 在get代码的①和②之间，另一个线程修改了一个entry的value
value是用volitale修饰的，可以保证读取时获取到的是修改后的值。
3) 在get代码的①之后，另一个线程删除了一个entry
假设我们的链表元素是：e1-> e2 -> e3 -> e4 我们要删除 e3这个entry，因为HashEntry中next的不可变，所以我们无法直接把e2的next指向e4，而是将要删除的节点之前的节点复制一份，形成新的链表。
它的实现大致如下图所示：
如果我们get的也恰巧是e3，可能我们顺着链表刚找到e1，这时另一个线程就执行了删除e3的操作，而我们线程还会继续沿着旧的链表找到e3返回。这里没有办法实时保证了。
我们第①处就判断了count变量，它保障了在 ①处能看到其他线程修改后的。①之后到②之间，如果再次发生了其他线程再删除了entry节点，就没法保证看到最新的了。
不过这也没什么关系，即使我们返回e3的时候，它被其他线程删除了，暴漏出去的e3也不会对我们新的链表造成影响。
这其实是一种乐观设计，设计者假设 ①之后到②之间 发生被其它线程增、删、改的操作可能性很小，所以不采用同步设计，而是采用了事后（其它线程这期间也来操作，并且可能发生非安全事件）弥补的方式。
而因为其他线程的“改”和“删”对我们的数据都不会造成影响，所以只有对“新增”操作进行了安全检查，就是②处的非null检查，如果确认不安全事件发生，则采用加锁的方式再次get。
这样做减少了使用互斥锁对并发性能的影响。可能有人怀疑remove操作中复制链表的方式是否代价太大，这里我没有深入比较，不过既然Java5中这么实现，我想new一个对象的代价应该已经没有早期认为的那么严重。
我们基本分析完了get操作。对于put和remove操作，是使用锁同步来进行的，不过是用的ReentrantLock而不是synchronized，性能上要更高一些。它们的实现前文都已经提到过，就没什么可分析的了。
我们还需要知道一点，ConcurrentHashMap的迭代器不是Fast-Fail的方式，所以在迭代的过程中别其他线程添加/删除了元素，不会抛出异常，也不能体现出元素的改动。但也没有关系，因为每个entry的成员除了value都是final修饰的，暴漏出去也不会对其他元素造成影响。
加深
ConcurrentHashMap<String, Boolean> map = new ...;
Thread a = new Thread {
void run() {
map.put("first", true);
map.put("second", true);
}
};
Thread b = new Thread {
void run() {
map.clear();
}
};
a.start();
b.start();
a.join();
b.join();
结果：
Map("first" -> true, "second" -> true)
Map("second" -> true)
Map()
Map("first" -> true)
ConcurrentHashMap<String, Boolean> map = new ...;
List<String> myKeys = new ...;
Thread a = new Thread {
void run() {
map.put("first", true);
// more stuff
map.remove("first");
map.put("second", true);
}
};
Thread b = new Thread {
void run() {
Set<String> keys = map.keySet();
for (String key : keys) {
myKeys.add(key);
}
}
};
a.start();
b.start();
a.join();
b.join();
结果：
List()
List("first")
List("second")
List("first", "second")
解释：
对于这两个现象的解释：ConcurrentHashMap中的clear方法：
public void clear() {
for (int i = 0; i < segments.length; ++i)
segments[i].clear();
}
如果线程b先执行了clear，清空了一部分segment的时候，线程a执行了put且正好把“first”放入了“清空过”的segment中，而把“second”放到了还没有清空过的segment中，就会出现上面的情况。
第二段代码，如果线程b执行了迭代遍历到first，而此时线程a还没有remove掉first，那么即使后续删除了first，迭代器里不会反应出来，也不抛出异常，这种迭代器被称为“弱一致性”(weakly consistent)迭代器。