深入理解Java容器-HashMap和ConcurrentHashMap

HashMap 1.7

众所周知 HashMap 底层是基于数组 + 链表组成的，不过在 jdk1.7 和 1.8 中具体实现稍有不同。
1.7中的HashMap数据结构：

核心成员变量

1.初始化桶大小，因为底层是数组，所以这是数组默认的大小。
2.桶最大值。
3.默认的负载因子（0.75）
4.table 真正存放数据的数组。
5.Map 存放数量的大小。
6.桶大小，可在初始化时显式指定。
7.负载因子，可在初始化时显式指定。

关于负载因子

给定的默认容量为 16，负载因子为 0.75。Map 在使用过程中不断的往里面存放数据，当数量达到了16 * 0.75 = 12就需要将当前 16 的容量进行扩容，而扩容这个过程涉及到 rehash、复制数据等操作，所以非常消耗性能。

因此通常建议能提前预估 HashMap 的大小最好，尽量的减少扩容带来的性能损耗。

主要方法

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;
}

• 判断当前数组是否需要初始化。
• 如果 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 。

1.8版本的升级

1.7版本上有一个非常明显的可以优化的地方：当 Hash 冲突严重时，在桶上形成的链表会变的越来越长，这样在查询时的效率就会越来越低；时间复杂度为 O(N)。1.8重点对此进行了优化。
1.8版本HashMap数据结构:

和1.7的主要区别

• TREEIFY_THRESHOLD用于判断是否需要将链表转换为红黑树的阈值。
• HashEntry 修改为 Node。Node 的核心组成其实也是和 1.7 中的 HashEntry 一样，存放的都是 key value hashcode next 等数据。

put方法

1. 判断当前桶是否为空，空的就需要初始化（resize 中会判断是否进行初始化）。
2. 根据当前 key 的 hashcode 定位到具体的桶中并判断是否为空，为空表明没有 Hash 冲突 就直接在当前位置创建一个新桶即可。
3. 如果当前桶有值（ Hash 冲突），那么就要比较当前桶中的 key、key 的 hashcode 与写入的 key 是否相等，相等就赋值给 e,在第 8 步的时候会统一进行赋值及返回。
4. 如果当前桶为红黑树，那就要按照红黑树的方式写入数据。
5. 如果是个链表，就需要将当前的 key、value 封装成一个新节点写入到当前桶的后面（形成链表）。
6. 接着判断当前链表的大小是否大于预设的阈值，大于时就要转换为红黑树。
7. 如果在遍历过程中找到 key 相同时直接退出遍历。
8. 如果 e != null 就相当于存在相同的 key,那就需要将值覆盖。
9. 最后判断是否需要进行扩容。

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();
}

扩容的时候调用 resize() 方法，这里的并发操作容易在一个桶上形成环形链表；当查找一个不存在的值时，会进入死循环。

红黑树

特点

1. 每个节点要么是红色，要么是黑色，但根节点永远是黑色的；
2. 每个红色节点的两个子节点一定都是黑色；
3. 红色节点不能连续（也即是，红色节点的孩子和父亲都不能是红色）；
4. 从任一节点到其子树中每个叶子节点的路径都包含相同数量的黑色节点；
5. 所有的叶节点都是是黑色的（注意这里说叶子节点其实是上图中的 NIL 节点）；

与链表的转换

若桶中链表元素超过8时，会自动转化成红黑树；若桶中元素小于等于6时，树结构还原成链表形式。
为什么是8？
红黑树的平均查找长度是log(n)，长度为8，查找长度为log(8)=3，链表的平均查找长度为n/2，当长度为8时，平均查找长度为8/2=4，这才有转换成树的必要；链表长度如果是小于等于6，6/2=3，虽然速度也很快的，但是转化为树结构和生成树的时间并不会太短。
为什么是6？
中间有个差值7可以防止链表和树之间频繁的转换。假设一下，如果设计成链表个数超过8则链表转换成树结构，链表个数小于8则树结构转换成链表，如果一个HashMap不停的插入、删除元素，链表个数在8左右徘徊，就会频繁的发生树转链表、链表转树，效率会很低。

ConcurrentHashMap 1.7

结构图:

由 Segment 数组、HashEntry组成，和 HashMap 一样，仍然是数组加链表。

它的核心成员变量：

/**
 * 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和next使用volatile关键字修饰，保证了获取时的可见性。

ConcurrentHashMap 采用了分段锁技术，其中 Segment 继承于 ReentrantLock。不会像 HashTable 那样不管是 put 还是 get 操作都需要做同步处理，理论上 ConcurrentHashMap 支持 CurrencyLevel (Segment 数组数量)的线程并发。每当一个线程占用锁访问一个 Segment 时，不会影响到其他的 Segment。

put方法

1. 首先是通过 key 定位到 Segment，之后在对应的 Segment 中进行具体的 put。
2. 虽然 HashEntry 中的 value 是用 volatile 关键词修饰的，但是并不能保证并发的原子性，所以 put 操作时仍然需要加锁处理。
3. 首先尝试获取Segment锁，如果获取失败表示有其他线程存在竞争，则利用scanAndLockForPut() 自旋获取锁。
   3.1 尝试自旋获取锁。
   3.2 如果重试的次数达到了 MAX_SCAN_RETRIES 则改为阻塞锁获取，保证能获取成功。

流程：

• 将当前 Segment 中的 table 通过 key 的 hashcode 定位到 HashEntry。
• 遍历该 HashEntry，如果不为空则判断传入的 key 和当前遍历的 key 是否相等，相等则覆盖旧的 value。
• 不为空则需要新建一个 HashEntry 并加入到 Segment 中，同时会先判断是否需要扩容。
• 最后会解除当前 Segment 的锁。

Get方法

get 逻辑比较简单：

• 将 Key 通过 Hash 之后定位到具体的 Segment ，再通过一次 Hash 定位到具体的元素上。
• 由于 HashEntry 中的 value 属性是用 volatile 关键词修饰的，保证了内存可见性，所以每次获取时都是最新值。

ConcurrentHashMap 的 get 方法是非常高效的，因为整个过程都不需要加锁。

ConcurrentHashMap 1.8

1.7 已经解决了并发问题，并且能支持 N 个 Segment 这么多次数的并发，但依然存在 HashMap 1.7 版本中的问题。那就是查询遍历链表效率太低。因此 1.8 做了一些数据结构上的调整。
底层的组成结构：

抛弃了原有的 Segment 分段锁，而采用了 CAS + synchronized 来保证并发安全性。
和1.7的HashEntry实现一样，value和next用volatile修饰，只是改名为Node。

把链表改为了红黑树，提高了查询效率，ReentrantLock改为了Synchronized。

参考链接：https://crossoverjie.top/2018/07/23/java-senior/ConcurrentHashMap/