Java HashMap 和 ConcurrentHashMap
HashMap? ConcurrentHashMap? 相信看完这篇没人能难住你！
前言
Map 这样的 Key Value 在软件开发中是非常经典的结构，常用于在内存中存放数据。
本篇主要想讨论 ConcurrentHashMap 这样一个并发容器，在正式开始之前我觉得有必要谈谈 HashMap，没有它就不会有后面的 ConcurrentHashMap。
HashMap
众所周知 HashMap 底层是基于 数组 + 链表 组成的，不过在 jdk1.7 和 1.8 中具体实现稍有不同。
Base 1.7
1.7 中的数据结构图：
HashMap 中比较核心的几个成员变量：
- 初始化桶大小，因为底层是数组，所以这是
数组默认的大小，默认16。 - 桶最大值。
- 默认的
负载因子（0.75） - table 真正存放数据的数组。
- Map 存放数量的大小。
- 桶大小，可在初始化时显式指定。
- 负载因子，可在初始化时显式指定。
解释下负载因子：给定的默认容量为 16，负载因子为 0.75。Map 在使用过程中不断的往里面存放数据，当数量达到了 16 * 0.75 = 12 就需要将当前 16 的容量进行扩容，而扩容这个过程涉及到 rehash、复制数据等操作，所以非常消耗性能。因此通常建议能提前预估 HashMap 的大小最好，尽量的减少扩容带来的性能损耗。
由于给定的 HashMap 的容量大小是固定的，比如默认初始化：
public HashMap() {
this(DEFAULT_INITIAL_CAPACITY, DEFAULT_LOAD_FACTOR);
}
public HashMap(int initialCapacity, float loadFactor) {
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +
initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " +
loadFactor);
this.loadFactor = loadFactor;
threshold = initialCapacity;
init();
}
根据代码可以看到其实真正存放数据的是Entry<K,V>[] table，Entry 是 HashMap 中的一个内部类，从他的成员变量很容易看出：
key就是写入时的键。value自然就是值。nextHashMap 是由数组和链表组成，next 就是用于实现链表结构。hash存放的是当前 key 的 hashcode。
put 方法
public V put(K key, V value) {
if (table == EMPTY_TABLE) {
inflateTable(threshold);
}
if (key == null)
return putForNullKey(value);
int hash = hash(key);
int i = indexFor(hash, table.length);
for (Entry<K,V> e = table[i]; e != null; e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}
modCount++;
addEntry(hash, key, value, i);
return null;
}
put步骤：
- 判断当前数组是否需要初始化。
- 如果
key 为空，则put 一个空值进去。 - 根据 key 计算出 hashcode。
- 根据计算出的 hashcode
定位出所在桶。 - 如果桶是一个链表则需要
遍历判断里面的 hashcode、key 是否和传入 key 相等，如果相等则进行覆盖，并返回原来的值。 - 如果
桶是空的，说明当前位置没有数据存入；新增一个Entry 对象写入当前位置。
void addEntry(int hash, K key, V value, int bucketIndex) {
if ((size >= threshold) && (null != table[bucketIndex])) {
resize(2 * table.length);
hash = (null != key) ? hash(key) : 0;
bucketIndex = indexFor(hash, table.length);
}
createEntry(hash, key, value, bucketIndex);
}
void createEntry(int hash, K key, V value, int bucketIndex) {
Entry<K,V> e = table[bucketIndex];
table[bucketIndex] = new Entry<>(hash, key, value, e);
size++;
}
- 当
调用 addEntry 写入 Entry 时需要判断是否需要扩容。 - 如果需要就
进行两倍扩充，并将当前的 key 重新 hash 并定位。 - 而在 createEntry 中会将当前位置的桶传入到新建的桶中，如果当前桶有值就会在位置形成链表。
get 方法
public V get(Object key) {
if (key == null)
return getForNullKey();
Entry<K,V> entry = getEntry(key);
return null == entry ? null : entry.getValue();
}
final Entry<K,V> getEntry(Object key) {
if (size == 0) {
return null;
}
int hash = (key == null) ? 0 : hash(key);
for (Entry<K,V> e = table[indexFor(hash, table.length)];
e != null;
e = e.next) {
Object k;
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
return e;
}
return null;
}
- 首先也是根据 key
计算出 hashcode，然后定位到具体的桶中。 - 判断该位置
是否为链表。 不是链表就根据 key、key 的 hashcode 是否相等来返回值。为链表则需要遍历直到 key 及 hashcode 相等时候就返回值。- 啥都没取到就
直接返回 null。
Base 1.8
Base 1.7 很明显缺陷是，当 Hash 冲突严重时，在桶上形成的链表会变的越来越长，这样在查询时的效率就会越来越低；时间复杂度为 O(N)。为了降低这部分的开销，在 JDK 1.8 中，当链表中的元素超过 8 个以后，会 将链表转换为红黑树，在这些位置进行查找的时候可以降低时间复杂度为 O(logN)。1.8 中重点优化了这个查询效率，其由数组+链表+红黑树组成。
1.8 HashMap 结构图：
核心的成员变量，和 1.7 大体上都差不多，还是有几个重要的区别：
- TREEIFY_THRESHOLD 用于判断
是否需要将链表转换为红黑树的阈值，默认 为 8。 - HashEntry 修改为 Node。Node 的核心组成其实也是和 1.7 中的 HashEntry 一样，存放的都是
key value hashcode next等数据。 - 红黑树的情况使用的是
TreeNode。根据数组元素中，第一个结点数据类型是Node 还是 TreeNode可以判断该位 置下是链表还是红黑树。
put 方法
看似要比 1.7 的复杂，我们一步步拆解：
- 判断
当前桶是否为空，空的就需要初始化（resize 中会判断是否进行初始化）。 - 根据当前 key 的 hashcode
定位到具体的桶中并判断是否为空，为空表明没有 Hash 冲突就直接在当前位置创建一个新桶即可。 - 如果当前桶有值（
Hash 冲突），那么就要比较当前桶中的key、key 的 hashcode 与写入的 key 是否相等，相等就赋值给 e,在第 8 步的时候会统一进行赋值及返回。 - 如果
当前桶为红黑树，那就要按照红黑树的方式写入数据。 - 如果是个
链表，就需要将当前的 key、value 封装成一个新节点写入到当前桶的后面（形成链表）。 - 接着
判断当前链表的大小是否大于预设的阈值，大于时就要转换为红黑树。 - 如果在遍历过程中找到 key 相同时直接退出遍历。
- 如果
e != null就相当于存在相同的 key,那就需要将值覆盖。 - 最后判断
是否需要进行扩容。
get 方法
public V get(Object key) {
Node<K,V> e;
return (e = getNode(hash(key), key)) == null ? null : e.value;
}
final Node<K,V> getNode(int hash, Object key) {
Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
if ((tab = table) != null && (n = tab.length) > 0 &&
(first = tab[(n - 1) & hash]) != null) {
if (first.hash == hash && // always check first node
((k = first.key) == key || (key != null && key.equals(k))))
return first;
if ((e = first.next) != null) {
if (first instanceof TreeNode)
return ((TreeNode<K,V>)first).getTreeNode(hash, key);
do {
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
return e;
} while ((e = e.next) != null);
}
}
return null;
}
- 首先将 key hash 之后取得所
定位的桶。 - 如果桶
为空则直接返回 null。 否则判断桶的第一个位置(有可能是链表、红黑树)的 key 是否为查询的 key，是就直接返回 value。- 如果第一个不匹配，则判断它的
下一个是红黑树还是链表。 - 红黑树就按照树的查找方式返回值。
- 不然就按照链表的方式遍历匹配返回值。
从这两个核心方法（get/put）可以看出 1.8 中对大链表做了优化，修改为红黑树之后查询效率直接提高到了 O(logn)。但是 HashMap 原有的问题也都存在，比如在并发场景下使用时容易出现死循环。
final HashMap<String, String> map = new HashMap<String, String>();
for (int i = 0; i < 1000; i++) {
new Thread(new Runnable() {
@Override
public void run() {
map.put(UUID.randomUUID().toString(), "");
}
}).start();
}
但是为什么呢？简单分析下。看过上文的还记得在 HashMap 扩容的时候会调用 resize() 方法，就是这里的并发操作容易在一个桶上形成环形链表；这样当获取一个不存在的 key 时，计算出的 index 正好是环形链表的下标就会出现死循环。
如下图：
遍历方式
还有一个值得注意的是 HashMap 的遍历方式，通常有以下几种：
Iterator<Map.Entry<String, Integer>> entryIterator = map.entrySet().iterator();
while (entryIterator.hasNext()) {
Map.Entry<String, Integer> next = entryIterator.next();
System.out.println("key=" + next.getKey() + " value=" + next.getValue());
}
Iterator<String> iterator = map.keySet().iterator();
while (iterator.hasNext()){
String key = iterator.next();
System.out.println("key=" + key + " value=" + map.get(key));
}
强烈建议使用第一种 EntrySet 进行遍历。第一种可以把 key value 同时取出，第二种还得需要通过 key 取一次 value，效率较低。
简单总结下 HashMap：无论是 1.7 还是 1.8 其实都能看出 JDK 没有对它做任何的同步操作，所以并发会出问题，甚至 1.7 中出现死循环导致系统不可用（1.8 已经修复死循环问题）。因此 JDK 推出了专项专用的 ConcurrentHashMap ，该类位于 java.util.concurrent 包下，专门用于解决并发问题。
ConcurrentHashMap
ConcurrentHashMap 同样也分为 1.7 、1.8 版，两者在实现上略有不同。
Base 1.7
先来看看 1.7 的实现，下面是他的结构图：
ConcurrentHashMap
- 由
Segment 数组、HashEntry 组成，和 HashMap 一样，仍然是数组+链表 - 采用了
分段锁技术，其中 Segment继承于 ReentrantLock。不会像 HashTable 那样不管是 put 还是 get 操作都需要做同步处理，理论上 ConcurrentHashMap支持 CurrencyLevel (Segment 数组数量)的线程并发。
关于分段锁
-
优势在于保证在操作不同段 map 的时候可以并发执行，操作同段 map 的时候，进行锁的竞争和等待。这
相对于直接对整个map同步 synchronized是有优势的。 -
缺点在于
分成很多段时会比较浪费内存空间(不连续，碎片化); 操作map时竞争 同一个分段锁的概率非常小时，分段锁反而会造成更新等操作的长时间等待; 当某个段很大时，分段锁的性能会下降。
核心成员变量：
/**
* Segment 数组，存放数据时首先需要定位到具体的 Segment 中。
*/
final Segment<K,V>[] segments;
transient Set<K> keySet;
transient Set<Map.Entry<K,V>> entrySet;
Segment 是 ConcurrentHashMap 的一个内部类，主要的组成如下：
static final class Segment<K,V> extends ReentrantLock implements Serializable {
private static final long serialVersionUID = 2249069246763182397L;
// 和 HashMap 中的 HashEntry 作用一样，真正存放数据的桶
transient volatile HashEntry<K,V>[] table;
transient int count;
transient int modCount;
transient int threshold;
final float loadFactor;
}
其中 HashEntry 的组成：和 HashMap 非常类似，唯一的区别就是其中的核心数据如 value 、链表都是 Volatile 修饰的，保证了获取时的可见性。
put 方法
public V put(K key, V value) {
Segment<K,V> s;
if (value == null)
throw new NullPointerException();
int hash = hash(key);
int j = (hash >>> segmentShift) & segmentMask;
if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck
(segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment
s = ensureSegment(j);
return s.put(key, hash, value, false);
}
final V put(K key, int hash, V value, boolean onlyIfAbsent) {
HashEntry<K,V> node = tryLock() ? null :
scanAndLockForPut(key, hash, value);
V oldValue;
try {
HashEntry<K,V>[] tab = table;
int index = (tab.length - 1) & hash;
HashEntry<K,V> first = entryAt(tab, index);
for (HashEntry<K,V> e = first;;) {
if (e != null) {
K k;
if ((k = e.key) == key ||
(e.hash == hash && key.equals(k))) {
oldValue = e.value;
if (!onlyIfAbsent) {
e.value = value;
++modCount;
}
break;
}
e = e.next;
}
else {
if (node != null)
node.setNext(first);
else
node = new HashEntry<K,V>(hash, key, value, first);
int c = count + 1;
if (c > threshold && tab.length < MAXIMUM_CAPACITY)
rehash(node);
else
setEntryAt(tab, index, node);
++modCount;
count = c;
oldValue = null;
break;
}
}
} finally {
unlock();
}
return oldValue;
}
- 首先是通过 key
定位到 Segment，之后在对应的 Segment 中进行具体的 put。 - 虽然 HashEntry 中的 value 是用 volatile 关键词修饰的，但是并不能保证并发的原子性，所以
put 操作时仍然需要加锁处理。 - 首先第一步的时候会
尝试获取锁，如果获取失败肯定就有其他线程存在竞争，则利用 scanAndLockForPut()自旋获取锁。 - 尝试自旋获取锁。
如果重试的次数达到了 MAX_SCAN_RETRIES则改为阻塞锁获取，保证能获取成功。
再结合图看看 put 的流程。
- 将当前 Segment 中的 table
通过 key 的 hashcode 定位到 HashEntry。 - 遍历该 HashEntry，如果不为空则
判断传入的 key 和当前遍历的 key 是否相等，相等则覆盖旧的 value。 - 不为空则需要
新建一个 HashEntry 并加入到 Segment 中，同时会先判断是否需要扩容。 - 最后会
解除在 1 中所获取当前 Segment 的锁。
get 方法
public V get(Object key) {
Segment<K,V> s; // manually integrate access methods to reduce overhead
HashEntry<K,V>[] tab;
int h = hash(key);
long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;
if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null &&
(tab = s.table) != null) {
for (HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile
(tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE);
e != null; e = e.next) {
K k;
if ((k = e.key) == key || (e.hash == h && key.equals(k)))
return e.value;
}
}
return null;
}
get 逻辑比较简单：
- 只需要将 Key
通过 Hash 之后定位到具体的 Segment，再通过一次 Hash 定位到具体的元素上。 - 由于 HashEntry 中的
value属性是用 volatile 关键词修饰的，保证了内存可见性，所以每次获取时都是最新值。 - ConcurrentHashMap 的
get 方法是非常高效的，因为整个过程都不需要加锁。
Base 1.8
1.7 已经解决了并发问题，并且能支持 N 个 Segment 这么多次数的并发，但依然存 在 HashMap 在 1.7 版本中的问题。那就是查询遍历链表效率太低。因此 1.8 做了一些数据结构上的调整。
- 红黑树：首先来看下底层的组成结构：其实和 1.8 HashMap 结构类似，当
链表节点数超过指定阈值的话，也是会转换成红黑树的，大体结构也是一样的。 - 实现线程安全：抛弃了原有的Segment 分段锁，而采用了
CAS + synchronized来保证 并发安全性。（cas：比较并替换）· - 将 1.7 中存放数据的 HashEntry 改为 Node，但作用都是相同的。其中的
val next都用了volatile 修饰，保证了可见性。
重要组成元素
-
Node：链表中的元素为 Node 对象。他是链表上的一个节点，内部存储了
key、 value、next。这样一系列的 Node 就串成一串，组成一个链表。 -
ForwardingNode：当进行扩容时，要把链表迁移到新的哈希表，在做这个操作时，会在
把数组中的头节点替换为 ForwardingNode 对象。ForwardingNode 中不保存 key 和 value，只保存了扩容后哈希表 （nextTable）的引用。此时查找相应 node 时，需要去 nextTable 中查找。 -
TreeBin：
当链表转为红黑树后，数组中保存的引用为 TreeBin，TreeBin 内部不保存 key/value，他保存了 TreeNode 的 list 以及红黑树 root。 -
TreeNode：
红黑树的节点。
put 方法
- 根据 key 计算出 hashcode 。
- 判断是否需要进行初始化。
- f 即为当前 key 定位出的 Node，如果为空表示当前位置可以写入数据，利用 CAS 尝试写入，失败则自旋保证成功。
- 如果当前位置的 hashcode == MOVED == -1,则需要进行扩容。
- 如果都不满足，则利用 synchronized 锁写入数据。
- 如果数量大于 TREEIFY_THRESHOLD 则要转换为红黑树。
get 方法
- 根据计算出来的 hashcode 寻址，如果就在桶上那么直接返回值。
- 如果是红黑树那就按照树的方式获取值。
- 就不满足那就按照链表的方式遍历获取值。
1.8 在 1.7 的数据结构上做了大的改动，采用红黑树之后可以保证查询效率（O(logn)），甚至取消了 ReentrantLock 改为了 synchronized，这样可以看出在新版的 JDK 中对 synchronized 优化是很到位的。
ConcurrentHashMap的size操作
如果我们要统计整个ConcurrentHashMap里元素的大小，就必须统计所有Segment里元素的大小后求和。Segment里的全局变量count是一个volatile变量，那么在多线程场景下，我们是不是直接把所有Segment的count相加就可以得到整个ConcurrentHashMap大小了呢？不是的，虽然相加时可以获取每个Segment的count的最新值，但是拿到之后可能累加前使用的count发生了变化，那么统计结果就不准了。所以最安全的做法，是在统计size的时候把所有Segment的put，remove和clean方法全部锁住，但是这种做法显然非常低效。
因为在累加count操作过程中，之前累加过的count发生变化的几率非常小，所以ConcurrentHashMap的做法是先尝试2次通过不锁住Segment的方式来统计各个Segment大小，如果统计的过程中，容器的count发生了变化，则再采用加锁的方式来统计所有Segment的大小。
那么ConcurrentHashMap是如何判断在统计的时候容器是否发生了变化呢？使用modCount变量，在put , remove和clean方法里操作元素前都会将变量modCount进行加1，那么在统计size前后比较modCount是否发生变化，从而得知容器的大小是否发生变化。
472
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
