ConcurrentHashMap源码分析1

一、背景：线程安全的HashMap

什么时候我们需要使用线程安全的hashmap呢，比如一个hashmap在运行的时候只有读操作，那么很明显不会有问题，但是当涉及到同时有改变也有读的时候，就要考虑线程安全问题了，在不考虑性能问题的时候，我们的解决方案有Hashtable或者Collections.synchronizedMap(hashMap)（注：可以是任何Map），这两种方式基本都是对整个hash表结构做锁定操作的，这样在锁表的期间，别的线程就需要等待了，无疑性能不高。

通过分析Hashtable就知道，synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术。它使用了多个锁来控制对hash表的不同部分进行的修改。ConcurrentHashMap内部使用段(Segment)来表示这些不同的部分，每个段其实就是一个小的hash table，它们有自己的锁。只要多个修改操作发生在不同的段上，它们就可以并发进行。

有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁。这里“按顺序”是很重要的，否则极有可能出现死锁，在ConcurrentHashMap内部，段数组是final的，并且其成员变量实际上也是final的，但是，仅仅是将数组声明为final的并不保证数组成员也是final的，这需要实现上的保证。这可以确保不会出现死锁，因为获得锁的顺序是固定的。

二、多线程的几个重要概念：

JAVA存储模型(JMM)的Happens-Before规则

理解两个点：

(1) java编译器的重排序(Reording)操作有可能导致执行顺序和代码顺序不一致。

简单解释为：假设代码有两条语句，代码顺序是语句1先于语句2执行；那么只要语句2不依赖于语句1的结果，打乱它们的顺序对最终的结果没有影响的话，那么真正交给CPU去执行时，他们的顺序可以是没有限制的。可以允许语句2先于语句1被CPU执行，和代码中的顺序不一致。

举个例子：

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未改变

前面三种可以理解，对于D，因为a=3;b=4;这两个操作互不影响，CPU执行时，执行顺序不确定，故出现D的结果。

小结：重排序（Reordering）是JVM针对现代CPU的一种优化，Reordering后的指令会在性能上有很大提升。(不知道这种优化对于多核CPU是否更加明显，也或许和单核多核没有关系。)

因为我们例子中的两条赋值语句，并没有依赖关系，无论谁先谁后结果都是一样的，所以就可能有Reordering的情况，这种情况下，对于其他线程来说就可能造成了可见性顺序不一致的问题。

(2)可见性一致问题:

在Java Memory Model中，Memory分为两类，main memory和working memory，main memory为所有线程共享，working memory中存放的是线程所需要的变量的拷贝（线程要对main memory中的内容进行操作的话，首先需要拷贝到自己的working memory，一般为了速度，working memory一般是在cpu的cache中的）。

其中有一个内存区域是jvm虚拟机栈，每一个线程运行时都有一个线程栈，线程栈保存了线程运行时候变量值信息。当线程访问某一个对象值的时候，首先通过对象的引用找到对应在堆内存的变量的值，然后把堆内存变量的具体值load到线程本地内存中，建立一个变量副本，之后线程就不再和对象在堆内存变量值有任何关系，而是直接修改副本变量的值，在修改完之后的某一个时刻（线程退出之前），自动把线程变量副本的值回写到对象在堆中变量。如下图所示：



read and load 从主存复制变量到当前工作内存

use and assign 执行代码，改变共享变量值

store and write 用工作内存数据刷新主存相关内容

假设例子中Reording后顺序仍与代码中的顺序一致，那么接下来呢？有意思的事情就发生在线程把Working Memery中的变量写回Main Memery的时刻。线程1把变量写回Main Memery的过程对线程2的可见性顺序也是无法保证的。

上面的列子，a=3; b=4; 这两个语句在 Working Memery中执行后，写回主存的过程对于线程2来说同样可能出现先b=4；后a=3；这样的相反顺序。

正因为上面的那些问题，JMM中一个重要问题就是：如何让多线程之间，对象的状态对于各线程的“可见性”是顺序一致的。它的解决方式就是 Happens-before 规则：

JMM为所有程序内部动作定义了一个偏序关系，叫做happens-before。要想保证执行动作B的线程看到动作A的结果（无论A和B是否发生在同一个线程中），A和B之间就必须满足happens-before关系。

后续分析ConcurrenHashMap时也会看到使用到锁(ReentrantLock)，Volatile，final等手段来保证happens-before规则的。

http://www.importnew.com/21781.html

http://www.importnew.com/21786.html

删除操作：

先定位到具体的HashEntry节点node，加入这个节点在链表的中间部分，因为HashEntry的属性next定义为final类型，不可以进行修改，因此我们将node的前面所有节点复制一份，重新连上node的下一个节点就可以。

举个例子：1-2-3-4；删除3，则删除后为2-1-4。

get操作：不用加锁

V get(Object key, int hash) {
1.     //read-volatile 当前桶的数据个数是否为0
2.     if (count != 0) {
3.         HashEntry<K,V> e = getFirst(hash);  得到头节点
4.         while (e != nu
4000
ll) {
5.             if (e.hash == hash && key.equals(e.key)) {
6.                 V v = e.value;
7.                 if (v != null)
8.                     return v;
9.                 return readValueUnderLock(e); // recheck
10.             }
11.             e = e.next;
12.         }
13.     }
14.     return null;
15. }

具体解释：

get操作不需要锁。第一步是访问count变量，这是一个volatile变量，由于所有的修改操作在进行结构修改时都会在最后一步写count 变量，通过这种机制保证get操作能够得到几乎最新的结构更新。对于非结构更新，也就是结点值的改变，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。接下来就是根据hash和key对hash链进行遍历找到要获取的结点，如果没有找到，直接访回null。对hash链进行遍历不需要加锁的原因在于链指针next是final的。但是头指针却不是final的，这是通过getFirst(hash)方法返回，也就是存在 table数组中的值。这使得getFirst(hash)可能返回过时的头结点，例如，当执行get方法时，刚执行完getFirst(hash)之后，另一个线程执行了删除操作并更新头结点，这就导致get方法中返回的头结点不是最新的。这是可以允许，通过对count变量的协调机制，get能读取到几乎最新的数据，虽然可能不是最新的。要得到最新的数据，只有采用完全的同步。

统计size方法：

要知道整个ConcurrentHashMap里元素的大小，就必须计算所有Segment里元素的大小然后求它们的和。Segment里的全局变量count是一个volatile变量，如果多线程场景下，我们是不是直接把所有Segment的count相加就可以拿到整个ConcurrentHashMap大小了？肯定不是这么简单的，虽然相加时可以获取每个Segment的count的最新值（volatile变量），但是拿到之后可能累加前使用的count发生了变化，那么统计结果就不一定准确了。所以最安全的做法，是在统计size的时候把所有Segment的put，remove和clean等方法全部锁住，这样就不会出现上面说的情况，但是这种做法显然非常低效。因为在累加count操作过程中，之前累加过的count发生变化的概率太小，所以ConcurrentHashMap的做法是先尝试2次通过不锁住Segment的方式来统计各个Segment大小，如果统计的过程中，容器的count发生了变化，则再采用加锁的方式来统计所有Segment的大小。那么ConcurrentHashMap是如何判断在统计的时候容器是否发生了变化呢？使用modCount变量，在put , remove和clean方法里操作元素前都会将变量modCount进行加1，那么在统计size前后比较modCount是否发生变化，从而得知容器的大小是否发生变化。