JDK集合类Collection解析--HashMap

HashMap源码解析

HashMap实现散列这一数据结构，维护一个散列表用于快速查询

内部结构

HashMap内部以词条(key-value)数组维护散列表，采用拉链法应对hash碰撞。
所谓词条数组指：具有相同键值key的元素放在一起。当然我们不能key唯一，可能且允许出现重复。当出现重复时，就发生了hash碰撞。
拉链法指：对于key相同，但是不equals的元素(即不能合并)，以链表的形式存储

重要参数

// HashMap中存储结构：词条数组
transient Node<K,V>[] table;
// 构造时不显示声明容量时的默认值
static final int DEFAULT_INITIAL_CAPACITY = 16;
// 链表树形化阈值：超过该值转为树
static final int TREEIFY_THRESHOLD = 8;
// 数组容量最小是64的时候才能树形化，否则一直扩容
static final int MIN_TREEIFY_CAPACITY = 64;
// 树转链表阈值：当树中结点小于该值，还原为链表
static final int UNTREEIFY_THRESHOLD = 6;
// 默认负载因子：当table中词条占容量的0.75时发生扩容
static final float DEFAULT_LOAD_FACTOR = 0.75f;

为什么扩容因子是0.75？
在容量为0.75的时候进行扩容，意味着还有0.25的空间可用，为何不充分利用这一空间呢？对于这个问题不能单单从空间上考虑，容量使用了0.75不仅意味着剩余0.25的空间，更意味着发生碰撞的概率是0.75。
那能否该为0.5呢？ 能，怎么不能，你写的程序听你的 0.5虽然降低了hash碰撞的可能，但是降低了空间利用率。所以0.75这个系数，是空间利用率和避免hash碰撞的折中

为什么链表的长度为8转换为树
1.首先，处于空间利用率的考虑
Because TreeNodes are about twice the size of regular nodes, we use them only when bins contain enough nodes to warrant use
以上为JDK注释原文：由于树结点是普通结点(链表结点)的两倍，因此我们要确保有足够多的点才能转换
虽然树查询快，但是在点不太多的情况快不到哪去，但是空间占一堆，所以结点太少就转化为树反而浪费空间资源，也并没有提升时间效率

2.从概率的角度来说：词条插入数组某一位置的概率 近似服从 泊松分布。由该模型可知，hash碰撞发生在同一位置上8次的可能性极小

• Ideally, under random hashCodes, the frequency of
  * nodes in bins follows a Poisson distribution
  * (http://en.wikipedia.org/wiki/Poisson_distribution) with a
  * parameter of about 0.5 on average for the default resizing
  * threshold of 0.75, although with a large variance because of
  * resizing granularity. Ignoring variance, the expected
  * occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
  * factorial(k)). The first values are:
  *
  * 0: 0.60653066
  * 1: 0.30326533
  * 2: 0.07581633
  * 3: 0.01263606
  * 4: 0.00157952
  * 5: 0.00015795
  * 6: 0.00001316
  * 7: 0.00000094
  * 8: 0.00000006
  * more: less than 1 in ten million

为什么树还要还原为链表？
And when they become too small (due to removal or resizing) they are converted back to plain bins.
以上为JDK注释原文：当树结点变少的时候，这些结点将重新变成链表
结合上一个问题，虽然树查询快，但是在点不太多的情况快不到哪去，但是空间占一堆，所以结点太少就转化为树反而浪费空间资源，也并没有提升时间效率

内部类

// 该类实现了词条(键值对)接口，是HashMap中的链表结点
 static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        V value;
        Node<K,V> next;		//链表后继
        ...
  }

// HashMap里的树结点，对对对，就那个红黑树(有生之年但愿能给看懂喽)
static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> {
    TreeNode<K,V> parent;  // red-black tree links
    TreeNode<K,V> left;
    TreeNode<K,V> right;
    TreeNode<K,V> prev;    // needed to unlink next upon deletion
    boolean red;
	...
}

构造方法

HashMap中table的构造不在构造器中实现，构造器仅负责设定参数，table的加载直到执行put方法时才执行

// 默认无参构造
public HashMap() {
	// 设定默认负载因子，然后。。。没了
    this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
}
// 虽然花里胡哨一大堆，就是多验了个数据合法，最后还是设定参数
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;
    this.threshold = tableSizeFor(initialCapacity);
}

HashMap容量的特别说明
在设定threshold时，并不是直接赋值，而是经过tableSizeFor函数，这个函数是将输入的int值转换为 大于该值的最小的2的幂次。如10->16
为啥呢？在put元素确定位置的时候就能发现这样做的巧妙之处了

常用方法

put

向table中添加词条，如果已存在添加的词条，覆盖更新，返回被覆盖的值(键值对中的value)

// 看起来是put
public V put(K key, V value) {
	// 这里传入的hash值可不是hashCode
    return putVal(hash(key), key, value, false, true);
}
// 真正执行put的操作
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
               boolean evict) {
    Node<K,V>[] tab; Node<K,V> p; int n, i;
    // 这里查看是否有初始化，没有resize扩容
    if ((tab = table) == null || (n = tab.length) == 0)
        n = (tab = resize()).length;
    // 底下这行确定插入位置
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null);
    else {
        Node<K,V> e; K k;
        if (p.hash == hash &&
            ((k = p.key) == key || (key != null && key.equals(k))))
            e = p;
        else if (p instanceof TreeNode)
            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
        else {
            for (int binCount = 0; ; ++binCount) {
                if ((e = p.next) == null) {
                    p.next = newNode(hash, key, value, null);
                    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                        treeifyBin(tab, hash);
                    break;
                }
                if (e.hash == hash &&
                    ((k = e.key) == key || (key != null && key.equals(k))))
                    break;
                p = e;
            }
        }
        if (e != null) { // existing mapping for key
            V oldValue = e.value;
            if (!onlyIfAbsent || oldValue == null)
                e.value = value;
            afterNodeAccess(e);
            return oldValue;
        }
    }
    ++modCount;
    if (++size > threshold)
        resize();
    afterNodeInsertion(evict);
    return null;
}

流程图

如何确定插入位置?
在JDK中，p = tab[i = (n - 1) & hash])确定插入位置，其等效于hash % n。
在前文中我们提到过，n = tab.length是2的幂次，因此n-1的二进制码必然是一堆0+一堆1，就比如000000…0011111，再经过&之后仅保留了后5位，实际也就是取余了。
此外，这个hash值也并非直接调用hashCode()，早在传入putVal()之前，就先经过hash()对key的hash值做预处理，将前16位与后16位异或(h = key.hashCode()) ^ (h >>> 16)。这样做是为了利用其高位信息来避免hash碰撞。如果一组数据的hash值仅高16位不同，而低16位完全相同，直接采用hash确定位置，可能需要扩容到2¹⁶才能发现他们不同；而加上高位信息则可能避免这种情况发生，使得hash尽可能离散

为什么重写hashCode也要重写equals
在put的过程中，首先获取对象的hashcode进而确定在hashmap中的位置，随后对该位置上的链表/tree查询是否重复。
现在考虑这样的问题：只重写equals而没有重写hashcode会发生什么？
先说结论，会重复。从逻辑上说，两对象相等<=>equals为true=>hashcode相同。显然两对象相等，那么hashcode一定相等；如果hashcode不同，则两对象一定不同。如果我们只重写了equals而没有重写hashcode，可能equals相同的对象，hashcode却不相同，进而在HashMap里存放了两个“不同”的对象
举例：数组{1,0,1,1}，hashcode认为其是一个从左向右的十进制数：1011；而equals认为这是一个从右向左的十进制数：1101。对于数组{1,0,1,1,0}，这两个函数发生了歧义，一个认为是10110，而另一个还是认定1101。HashMap中首先调用hashCode，导致明明是相同的对象却阴阳两隔，连调用equals判定的机会都没有

此外，HashMap与HashTable不同，HashMap允许key为null，对应的hash是0

resize

初始化或者将容量翻倍。如果为空，参照默认值初始化容量；不为空则容量扩一倍，原来的词条要么保持不动，要么移动一个常数距离。

final Node<K,V>[] resize() {
    Node<K,V>[] oldTab = table;
    int oldCap = (oldTab == null) ? 0 : oldTab.length;
    int oldThr = threshold;
    int newCap, newThr = 0;
    
	// 底下这一片，看着挺多的，但就干了一件事，确定新的容量
    if (oldCap > 0) {
        if (oldCap >= MAXIMUM_CAPACITY) {
            threshold = Integer.MAX_VALUE;
            return oldTab;
        }
        else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                 oldCap >= DEFAULT_INITIAL_CAPACITY)
            newThr = oldThr << 1; // double threshold
    }
    else if (oldThr > 0) // initial capacity was placed in threshold
        newCap = oldThr;
    else {               // zero initial threshold signifies using defaults
        newCap = DEFAULT_INITIAL_CAPACITY;
        newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
    }
    if (newThr == 0) {
        float ft = (float)newCap * loadFactor;
        newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                  (int)ft : Integer.MAX_VALUE);
    }
    threshold = newThr;
    // 一直到这

	// 建新的table
    @SuppressWarnings({"rawtypes","unchecked"})
    Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
    table = newTab;

	// 遍历原有的table，重新确定位置
    if (oldTab != null) {
        for (int j = 0; j < oldCap; ++j) {
            Node<K,V> e;
            if ((e = oldTab[j]) != null) {
                oldTab[j] = null;
                if (e.next == null)
                    newTab[e.hash & (newCap - 1)] = e;
                else if (e instanceof TreeNode)
                    ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                else { 
                	// 这一坨，看着也很多，但是说起来，就是把链表里位置变动的结点单独拿出来
                	// 又重写接了个链表给按到新位置上了
                    Node<K,V> loHead = null, loTail = null;
                    Node<K,V> hiHead = null, hiTail = null;
                    Node<K,V> next;
                    do {
                        next = e.next;
                        if ((e.hash & oldCap) == 0) {
                            if (loTail == null)
                                loHead = e;
                            else
                                loTail.next = e;
                            loTail = e;
                        }
                        else {
                            if (hiTail == null)
                                hiHead = e;
                            else
                                hiTail.next = e;
                            hiTail = e;
                        }
                    } while ((e = next) != null);
                    if (loTail != null) {
                        loTail.next = null;
                        newTab[j] = loHead;
                    }
                    if (hiTail != null) {
                        hiTail.next = null;
                        newTab[j + oldCap] = hiHead;
                    }
                }
            }
        }
    }
    return newTab;
}

关于扩容时，重新确定位置的小技巧
在插入时，hash和一堆1 & ；现在长度变了，hash和另一堆1 &。这两堆1差不多，就是一个比另一个长了一位，所以得出的pos就只有两种情况，新加的那一位是0，不动；是1，那就加个数，而且所有元素加的数都一样哦

get

返回指定key所映射的value，如果不存在key返回null。

返回null不代表一定没有，可能是某个key值map到了null。containsKey()可以用来区分二者。

这个源码真没啥好说的，遇树查树，遇表查表；有就返回，没有算完

线程安全版本：ConcurrentHashMap

属性

transient volatile Node<K,V>[] table;
//仅在扩容时非空
private transient volatile Node<K,V>[] nextTable;
/**
 * 控制数组的初始化和扩容
 * -1 ： 初始化
 * -(1 + the number of active resizing threads) 扩容
 * 0 数组长度为默认长度
 * table==null 表示需要新建数组的长度
 * 已经初始化 数组的有效容量(n*loadFactor)
 */
private transient volatile int sizeCtl;

其余参数与HashMap相同

构造器

构造器怎么写的不重要，重要的是ConcurrentHashMap和HashMap一样，都不在构造器中构建数组，只是设定参数

// 看着花里胡哨的，基本都在检验参数的合法性
// 可见人的输入能有多不靠谱
public ConcurrentHashMap(int initialCapacity,
                         float loadFactor, int concurrencyLevel) {
    if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
        throw new IllegalArgumentException();
    if (initialCapacity < concurrencyLevel)   // Use at least as many bins
        initialCapacity = concurrencyLevel;   // as estimated threads
    long size = (long)(1.0 + (long)initialCapacity / loadFactor);
    int cap = (size >= (long)MAXIMUM_CAPACITY) ?
        MAXIMUM_CAPACITY : tableSizeFor((int)size);
    this.sizeCtl = cap;
}

常见方法

put

get

get方法是不加锁的，和HashMap差不多 懒得写了

transfer

第一部分是构建一个 nextTable,它的容量是原来的两倍，这个操作是单线程完成的。新建 table 数组的代码为:Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1],在原容量大小的基础上右移一位。
第二个部分就是将原来 table 中的元素复制到 nextTable 中，主要是遍历复制的过程。
根据运算得到当前遍历的数组的位置 i，然后利用 tabAt 方法获得 i 位置的元素再进行判断：

1. 如果这个位置为空，就在原 table 中的 i 位置放入 forwardNode 节点，这个也是触发并发扩容的关键点
2. 如果这个位置是 Node 节点（fh>=0），如果它是一个链表的头节点，就构造一个反序链表，把他们分别放在 nextTable 的 i 和 i+n 的位置上
3. 如果这个位置是 TreeBin 节点（fh<0），也做一个反序处理，并且判断是否需要 untreefi，把处理的结果分别放在 nextTable 的 i 和 i+n 的位置上
4. 遍历过所有的节点以后就完成了复制工作，这时让 nextTable 作为新的 table，并且更新 sizeCtl 为新容量的 0.75 倍 ，完成扩容。设置为新容量的 0.75 倍代码为 sizeCtl = (n << 1) - (n >>> 1)，仔细体会下是不是很巧妙，n<<1 相当于 n 左移一位表示 n 的两倍即 2n,n>>>1，n 右移相当于 n 除以 2 即 0.5n,然后两者相减为 2n-0.5n=1.5n,是不是刚好等于新容量的 0.75 倍即 2n*0.75=1.5n。

作者：你听___ 链接：https://juejin.im/post/6844903602423595015 来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

JDK1.7：Segment

将数组分段，对每一段segment独立上锁，这样最多可以有 numberOf(segment)线程同时对ConcurrentHashMap进行操作，提高吞吐量
图片链接

---

参考链接：

1. 第六章 Java数据结构和算法 之 容器类（一）
2. 并发容器之ConcurrentHashMap(JDK 1.8版本)