标签：
ConcurrentHashMap源码阅读以及底层实现的简单分析
ConcurrentHashMap 是可以实现多线程并发的HashMap，它是线程安全的。
前面分析过 HashMap的源码，它和HashMap有很多的相同点一样，比如它也有 initialCapacity 以及负载因子 loadFactor 属性。而且他们的默认值也是16和0.75.
static final int DEFAULT_INITIAL_CAPACITY =16;
static final float DEFAULT_LOAD_FACTOR =0.75f;
和HashMap不同的是，它还多了一个concurrencyLevel属性，它的默认值也是16。
static final int DEFAULT_CONCURRENCY_LEVEL = 16;
从名字就可以看出他的作用是调节并发的粒度。也就是把HashMap的数组分成的segment的个数，ConcurrentHashMap就是通过Segment来对这个数组分段来实现细粒度的加锁，实现高并发，下面会进行介绍。当以上的三个参数都为默认值的时候，会计算一个ssize值，就是Segment数组的大小，具体代码如下所示：
int ssize = 1;
while (ssize <concurrencyLevel) {
++sshift;
ssize <<= 1;
}
由于concurrencyLevel 为 16，一直执行while循环，直到 ssize 为 16，并使用此 ssize 作为参数传入 Segment 的 newArray 方法，创建大小为 16 的 Segment 对象数组，代码如下所示：
Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize];
接着又计算 cap 变量的值，具体实现的代码如下所示：
int c = initialCapacity / ssize;
if (c * ssize <initialCapacity)
++c;
int cap =MIN_SEGMENT_TABLE_CAPACITY;
while (cap < c)
cap <<= 1;
根据以上参数值，可以计算出cap 为 1，最后为 Segment 对象数组创建 Segment 对象，传入的参数为 cap 和 loadFactor，Segment 对象继承 ReentrantLock，在创建 Segment 对象时，其所做的动作为创建一个指定大小为 cap 的 HashEntry 对象数组，并基于数组的大小以及loadFactor 计算 threshold 的值：
threshold = (int)(newCapacity * loadFactor);
下面以put方法为入口，进行分析。
ConcurrentHashMap 并没有在此方法上加上 synchronized，首先判断 value 是否为 null，如为 null 则抛出 NullPointerException，如不为 null，则继续下面的步骤：
首先对key.hashCode 进行 hash 操作，得到 key 的 hash 值，hash 操作的算法和 HashMap 也不同：
根据此 hash 值计算并获取其对应的数组中的 Segment 对象，具体的代码如下：
return segments[(hash >>> segmentShift) & segmentMask];
在找到了数组中的Segment对象后，接着调用Segment对象的put方法来完成当前操作。
当调用 Segment 对象的 put 方法时，首先进行 lock操作，接着判断当前存储的对象个数加 1 后是否大于 threshold，如大于，则将当前的 HashEntry 对象数组大小扩大两倍，并将之前存储的对象进行重新 hash，转移到新的对象数组中，在确保了数组的大小足够后，继续向下执行。
下面基本上和HashMap 的操作一样，通过对 hash 值和对象数组大小减 1 的值进行按位与后，得到当前 key 需要放入数组的位置，接着就遍历整个链表，来寻找对应的位置上的 HashEntry 对象链表是否有 key、hash 值和当前 key 相同的，如有，覆盖其 value，如没有，则创建一个新的HashEntry 对象，赋值给对应位置的数组对象，并构成链表。这里的HashEntry类似于HashMap中的Entry。
上面的步骤完成了以后后，就释放了锁，整个 put 动作得以完成。
根据以上分析，可以看出，ConcurrentHashMap基于 concurrencyLevel 划分出了多个Segment 段来对 key-value 进行存储，从而避免每次 put 操作就得锁住整个数组，所以在默认的情况下，最好的情况下可以允许 16 个线程并发无阻塞的操作集合对象，实现了锁的粒度的减小，可以更大程度的实现并发。
然后来看看get(Objectkey) 方法
开始先对key.hashCode 进行 hash 操作，基于得到 hash 的值找到对应的 Segment 对象，调用Segment的 get 方法完成当前操作。通过对比可以发现，比HashMap多了一次寻找Segment的操作。
进入Segment 的 get 方法以后，首先判断当前HashEntry 对象数组中的已存储的对象大小是否为 0，如为 0，则直接返回 null，如不为 0，则继续执行下面的代码。
首先类似于HashMap，先进行hash计算，算法也和HashMap类似，找到对应的数组的下标，然后一样先遍历整个链表，寻找到 hash 值相等以及 key equals 的HashEntry 对象，在找到的情况下，获取其 value，如 value 不为 null，则直接返回此 value，如为 null，则调用 readValueUnderLock 方法，readValueUnderLock 方法首先进行 lock 操作，然后直接返回 HashEntry 的 value 属性，最后释放锁。
所有的各种做完以后，就完成了 get 操作，从上面 Segment 的 get 步骤来看，仅在寻找到的HashEntry 对象的 value 为 null 时，才进行了锁操作，其他情况下并没有锁操作，也就是可以认为 ConcurrentHashMap 在读数据时大部分情况下是没有采用锁的，那么它是如何保证并发场景下数据的一致性的呢。
开始的时候，没有查看源代码，我还以为它使用的是读写锁，结果发现读操作恰恰没有加锁，对源码进行分析，发现get 操作首先还是计算数组下标，来找对应的HashEntry的位置，但是在这个步骤中，可能会因为对象数组大小的改变以及数组上对应位置的 HashEntry 产生不一致性，下面就来看看它是如何实现的。
可以发现，它是通过voliate关键字来实现的可见性，对象数组大小的改变只有在 put 操作时有可能发生，由于 HashEntry 对象数组对应的变量是 voliate 类型的，因此可以保证如 HashEntry 对象数组大小发生改变，读操作时可看到最新的对象数组大小。
但是有一个问题，就是在put和remove操作进行时，都有可能造成HashEntry对象数组上对应位置的HashEntry发生改变，如在读操作已获取到 HashEntry 对象后，有一个 put 或 remove 操作完成，此时读操作尚未完成，那么这时会造成读的不一致性，不过这种情况不太容易出现。
在获取到了HashEntry 对象后，怎么能保证获取的 HashEntry 对象以及其 next 属性构成的链表上的对象不会改变呢，这点 ConcurrentHashMap 采用了一个简单的方式，即 HashEntry对象中的 hash、key 以及 next 属性都是 final 的，这也就意味着没办法插入一个 HashEntry对象到HashEntry基于next属性构成的链表中间或末尾中，这样可以保证当获取到HashEntry对象后，其基于 next 属性构建的链表是不会发生变化的。
至于为什么需要判断下获取的HashEntry 的 value 是否为 null，原因在于 put 操作创建一个新的 HashEntry 时，并发读取时有可能此时 value 属性尚未完成设置，因此将读取到默认值，不过具体出现这种现象的原因还未知，据说只有在老版本的 JDK 中才会有，而其他属性，由于是 final 的，则可以保证是线程安全的，因此这里做了个保护，当 value 为 null 则通过加锁操作来确保读到的 value 是一致的。
最后再来看看remove(Objectkey) 方法
首先对key.hashCode 进行 hash 操作，找到它对应的 Segment 对象，再调用Segment 的remove 方法完成当前操作。
Segment 的 remove 方法进行加锁操作，然后计算出在下标，在对这个数组当前下标的元素链表遍历，找到 hash 和传入的 hash 值相等，以及 key 和传入的 key equals 的 HashEntry对象，如未找到，则返回 null。如找到，则将 HashEntry 链表中位于删除元素之前的所有 HashEntry 重新创建，之所以这样，是因为上面提到的，next 属性都被设计成了 final 的，不能进行改变。但是在他后面的元素就不用任何的操作。所有的操作完成之后，就释放了锁，完成了删除的操作。
通过分析源码可以发现，ConcurrentHashMap比HashMap多了一个操作，就是分段，默认使用一个长度16的Segment数组实现，然后每一个Segment元素类似于HashMap中的Entry数组。而对于ConcurrentHashMap的所有的写操作，即增删，都会加锁，对于读的操作却没有加锁，使用voliate关键字来保证了可见性。
ConcurrentHashMap源码阅读以及底层实现的简单分析
标签：
原文地址：http://blog.csdn.net/qfycc92/article/details/45442919
