Java HashMap

HashMap 存储的是 key-value 的键值对，**允许 key 为 null，也允许 value 为 null。**key 为 null 的键值对永远都放在以 table[0] 为头结点的链表中。

HashMap 内部为数组 + 链表的结构，会根据 key 的 hashCode 值来确定数组的索引(确认放在哪个桶里)，如果发生hash冲突，HashMap 会将同一个桶中的数据以链表的形式存储，但是如果发生hash冲突的概率比较高，就会导致同一个桶中的链表长度过长，遍历效率降低，所以在 JDK1.8 中如果链表长度到达阀值(默认是 8 )，就会将链表转换成红黑二叉树。

public class HashMap<K,V>
	extends AbstractMap<K,V>
	implements Map<K,V>, Cloneable, Serializable {}

构造函数

HashMap 提供了三个构造函数（1.7）：

• HashMap()：构造一个具有默认初始容量 (16) 和默认加载因子 (0.75f) 的空 HashMap。
• HashMap(int initialCapacity)：构造一个带指定初始容量和默认加载因子 (0.75) 的空 HashMap。
• HashMap(int initialCapacity, float loadFactor)：构造一个带指定初始容量和加载因子的空 HashMap。

1.8：HashMap(Map<? extends K, ? extends V> m)

初始容量和加载因子是影响 HashMap 性能的重要参数，其中容量表示哈希表中桶的数量，初始容量是创建哈希表时的容量。加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度，它衡量的是一个散列表的空间的使用程度，负载因子越大表示散列表的装填程度越高，反之愈小。

对于使用链表法的散列表来说，查找一个元素的平均时间是 O(1 + a)，因此如果负载因子越大，对空间的利用更充分，然而后果是查找效率的降低；如果负载因子太小，那么散列表的数据将过于稀疏，对空间造成严重浪费。系统默认负载因子为0.75，一般情况下我们是无需修改的。

内部数据结构

HashMap 内部包含一个 Node<K,V>[] table，其中 Node 的定义如下：

// Node实现了Map.Entry接口，本质上是一个映射(k-v)
static class Node<K,V> implements Map.Entry<K,V> {
    final int hash;	//保存该桶的hash值
    final K key;
    V value;
    Node<K,V> next;

    Node(int hash, K key, V value, Node<K,V> next) {
        this.hash = hash;
        this.key = key;
        this.value = value;
        this.next = next;
    }
	// ...
}

HashMap 底层实现还是数组，只是数组的每一项都是一个 Node（视作一条链）。

字段

// 默认桶 16 个
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16

// 默认桶最多有 2^30 个
static final int MAXIMUM_CAPACITY = 1 << 30;

// 默认负载因子是 0.75
static final float DEFAULT_LOAD_FACTOR = 0.75f;

// 能容纳最多 key-value 对的个数
int threshold;

// 一共 key-value 对个数
int size;

threshold = 负载因子 * length，也就是说数组长度固定以后， 如果负载因子越大，所能容纳的元素个数越多，如果超过这个值就会进行扩容(默认是扩容为原来的2倍)，0.75 这个值是权衡过空间和时间得出的，建议不要随意修改，如果在一些特殊情况下，比如空间比较多，但要求速度比较快，这时候就可以把扩容因子调小以较少hash冲突的概率。相反就增大扩容因子(这个值可以大于1)。

size 就是 HashMap 中键值对的总个数。还有一个字段是 modCount，记录是发生内部结构变化的次数，put 不算，put的值是覆盖原有的值，这样是不算内部结构变化的。

因为 HashMap 扩容每次都是扩容为原来的 2 倍，所以 length 总是 2 的次方（初始值 16），这是非常规的设置，常规设置是把桶的大小设置为素数，因为素数发生hash冲突的概率要小于合数，比如 HashTable 的默认值设置为11，就是桶的大小为素数的应用( HashTable 扩容后不能保证是素数)。HashMap 采用这种设置是为了在取模和扩容的时候做出优化。

HashMap 是通过 key 的 hashCode 的高 16 位和低 16 位异或后和桶的数量取模得到索引位置，即key.hashcode() ^ (hashcode >>> 16) % length ,当 length 是 2 ^ n 时，h &（length-1）运算等价于 h % length，而 & 操作比 % 效率更高。而采用高 16 位和低 16 位进行异或，也可以让所有的位数都参与越算，使得在 length 比较小的时候也可以做到尽量的散列。

在扩容的时候，如果 length 每次是2 ^ n，那么重新计算出来的索引只有两种情况，一种是 old 索引 + 16，另一种是索引不变，所以就不需要每次都重新计算索引。

确定哈希桶数据索引位置

//方法一：
static final int hash(Object key) {   //jdk1.8 & jdk1.7
     int h;
     // h = key.hashCode() 为第一步 取hashCode值
     // h ^ (h >>> 16)  为第二步 高位参与运算
     return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
//方法二：
static int indexFor(int h, int length) {  //jdk1.7的源码，jdk1.8没有这个方法，但是实现原理一样的
     return h & (length - 1);  //第三步 取模运算
}

HashMap 的 put 方法实现

思路如下：

1.table[] 是否为空

2.判断 table[i] 处是否插入过值

3.判断链表长度是否大于8，如果大于就转换为红黑二叉树，并插入树中

4.判断 key 是否和原有 key 相同，如果相同就覆盖原有 key 的 value，并返回原有 value

5.如果 key 不相同，就插入一个 key，记录结构变化一次

final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
	//判断table是否为空，如果是空的就创建一个table，并获取他的长度
	Node<K,V>[] tab; Node<K,V> p; int n, i;
    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;
		//判断put的数据和之前的数据是否重复
        if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k))))   		//key的地址或 key 的 equals() 只要有一个相等就认为key重复了，就直接覆盖原来key的value
			e = p;
		//判断是否是红黑树，如果是红黑树就直接插入树中
        else if (p instanceof TreeNode)
			e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
		else {
			//如果不是红黑树，就遍历每个节点，判断链表长度是否大于8，如果大于就转换为红黑树
            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;
                }
				//判断索引每个元素的key是否可要插入的key相同，如果相同就直接覆盖
            	if (e.hash == hash && 
                    ((k = e.key) == key || (key != null && key.equals(k))))
           	 		break;
            	p = e;
            }
		}
		//如果e不是null，说明没有迭代到最后就跳出了循环，说明链表中有相同的key，因此只需要将value覆盖，并将oldValue返回即可
        if (e != null) { // existing mapping for key
            V oldValue = e.value;
            if (!onlyIfAbsent || oldValue == null)
                e.value = value;
            afterNodeAccess(e);
            return oldValue;
        }
    }
	//说明没有key相同，因此要插入一个key-value，并记录内部结构变化次数
    ++modCount;
    if (++size > threshold)
        resize();
    afterNodeInsertion(evict);
    return null;
}

HashMap 的 get 方法实现

实现思路：

1.判断表或 key 是否是null，如果是直接返回 null

2.判断索引处第一个 key 与传入 key 是否相等，如果相等直接返回

3.如果不相等，判断链表是否是红黑二叉树，如果是，直接从树中取值

4.如果不是树，就遍历链表查找

final Node<K,V> getNode(int hash, Object key) {
	Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
	//如果表不是空的，并且要查找索引处有值，就判断位于第一个的key是否是要查找的key
    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;
}

扩容机制

详细可看：

https://segmentfault.com/a/1190000015812438

我们使用的是 2 次幂的扩展(指长度扩为原来 2 倍)，所以，元素的位置要么是在原位置，要么是在原位置再移动 2次幂的位置。看下图可以明白这句话的意思，n 为 table的长度，图（a）表示扩容前的 key1 和 key2 两种 key 确定索引位置的示例，图（b）表示扩容后 key1 和 key2 两种 key 确定索引位置的示例，其中 hash1 是 key1 对应的哈希与高位运算结果。

元素在重新计算hash之后，因为n变为2倍，那么n-1的mask范围在高位多1bit(红色)，因此新的index就会发生这样的变化：

因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引 + oldCap”，可以看看下图为16扩充为32的resize示意图：

这个设计确实非常的巧妙，既省去了重新计算 hash 值的时间，而且同时，由于新增的 1bit 是 0 还是 1 可以认为是随机的，因此 resize 的过程，均匀的把之前的冲突的节点分散到新的 bucket 了。这一块就是 JDK1.8 新增的优化点。有一点注意区别，JDK1.7 中 rehash 的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，JDK1.8不会倒置。

一些问题

转载自：

https://blog.csdn.net/qq_43519310/article/details/102887039

为什么会引入红黑树做查询优化？
在平常使用 HashMap 的时候，HashMap 里面存储的 key 是具有良好 hash 算法的 key (比如 String、Integer 等包装类)，冲突几率自然微乎其微，此时链表几乎不会转化为红黑树，但是当 key 是我们自定义的对象时，可能采用了不好的 hash 算法，使 HashMap 中 key 的冲突率极高，此时 HashMap 为了保证高效的查找效率，就引入了红黑树来优化查询。

为什么树化的临界值为 8 ？
通过源码得知 HashMap 源码作者通过泊松分布算出，当桶中结点个数为 8 时，出现的几率是亿分之 6，因此常见的情况是桶中个数小于 8 的情况，此时链表的查询性能和红黑树相差不多，因为转化为树还需要时间和空间，所以此时没有转化成树的必要。

既然个数为 8 时发生的几率这么低，为什么还要当链表个数大于 8 时来树化来优化这几乎不会发生的场景呢？

首先要知道亿分之 6 这个几乎不可能的概率是建立在良好的 hash 算法情况下，例如 String，Integer 等包装类的hash 算法，如果一旦发生桶中元素大于 8，说明是不正常情况，可能采用了冲突较大的 hash 算法，此时桶中个数出现超过 8 的概率是非常大的，可能有 n 个 key 冲突在同一个桶中，此时再看链表的平均查询复杂度和红黑树的时间复杂度，就知道为什么要引入红黑树了。

举个例子，若 hash 算法写的不好，一个桶中冲突 1024 个key，使用链表平均需要查询 512 次，但是红黑树仅仅需要10 次，红黑树的引入保证了在大量 hash 冲突的情况下，HashMap 还具有良好的查询性能。