HashMap

HashMap

在 JDK 1.7 中 HashMap 是以数组加链表的形式组成的，JDK 1.8 之后新增了红黑树的组成结构，当链表大于 8 时，链表结构会转换成红黑树结构，它的组成结构如下图所示：

数组中元素结构：

static class Node implements Map.Entry { final int hash; final K key; V value; Node next; }

JDK 1.8 之所以添加红黑树是因为一旦链表过长，会严重影响 HashMap 的性能，而红黑树具有快速增删改查的特点，这样就可以有效的解决链表过长时操作比较慢的问题。

HashMap 源码中包含了以下几个属性：

// HashMap 初始化长度 static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16 // HashMap 最大长度 static final int MAXIMUM_CAPACITY = 1 << 30; // 1073741824 // 默认的加载因子 (扩容因子) static final float DEFAULT_LOAD_FACTOR = 0.75f; // 转换红黑树的临界值，当链表长度大于此值时，会把链表结构转换为红黑树结构 static final int TREEIFY_THRESHOLD = 8; // 转换链表的临界值，当元素小于此值时，会将红黑树结构转换成链表结构 static final int UNTREEIFY_THRESHOLD = 6; // 最小树容量 static final int MIN_TREEIFY_CAPACITY = 64; 什么是加载因子？加载因子为什么是 0.75？

加载因子也叫扩容因子或负载因子，用来判断什么时候进行扩容的，假如加载因子是0.5，HashMap的初始化容量是16，那么当HashMap中有16*0.5=8个元素时，HashMap就会进行扩容。

为什么是0.75：

这其实是出于容量和性能之间平衡的结果：

当加载因子设置比较大的时候，扩容的门槛就被提高了，扩容发生的频率比较低，占用的空间会比较小，但此时发生 Hash 冲突的几率就会提升，因此需要更复杂的数据结构来存储元素，这样对元素的操作时间就会增加，运行效率也会因此降低；

而当加载因子值比较小的时候，扩容的门槛会比较低，因此会占用更多的空间，此时元素的存储就比较稀疏，发生哈希冲突的可能性就比较小，因此操作性能会比较高。

所以综合了以上情况就取了一个 0.5 到 1.0 的平均数 0.75 作为加载因子。

查询get, getNode public V get(Object key){ Nodee; //对key进行哈希操作 return (e = getNode(hash(key), key)) == null ? null : e.value; } final Node getNode(int hash, Object key) { Node[] tab; Node 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) { // 如果第一节点是树结构，则使用 getTreeNode 直接获取相应的数据 if (first instanceof TreeNode) return ((TreeNode)first).getTreeNode(hash, key); do {// 非树结构，循环节点判断 // hash 相等并且 key 相同，则返回此节点 if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k)))) return e; } while ((e = e.next) != null); } } return null; }

从以上源码可以看出，当哈希冲突时我们需要通过判断 key 值是否相等，才能确认此元素是不是我们想要的元素。

新增方法put, putVal public V put(K key, V value) { // 对 key 进行哈希操作 return putVal(hash(key), key, value, false, true); } final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) { Node[] tab; Node p; int n, i; // 哈希表为空则创建表 if ((tab = table) == null || (n = tab.length) == 0) n = (tab = resize()).length; // 根据 key 的哈希值计算出要插入的数组索引 i if ((p = tab[i = (n - 1) & hash]) == null) // 如果 table[i] 等于 null，表示该节点还没有元素则直接插入 else { Node e; K k; // 如果 key 已经存在了，直接覆盖 value if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k)))) e = p; // 如果 key 不存在，判断是否为红黑树 else if (p instanceof TreeNode) // 是红黑树，直接插入键值对 e = ((TreeNode)p).putTreeVal(this, tab, hash, key, value); else { // 否则为链表结构，循环准备插入 for (int binCount = 0; ; ++binCount) { // 下一个元素为空时（即链表的尾部插入） p.next = newNode(hash, key, value, null); // 插入后判断，链表长度大于 8 转换为红黑树进行处理 if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st treeifyBin(tab, hash); break; } // key 已经存在直接覆盖 value 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; }

扩容方法 resize final Node[] resize() // 扩容前的数组 Node[] oldTab = table; // 扩容前的数组的大小和阈值 int oldCap = (oldTab == null) ? 0 : oldTab.length; int oldThr = threshold; (capacity * load factor) // 预定义新数组的大小和阈值 int newCap, newThr = 0; if (oldCap > 0) { // 超过最大值就不再扩容了 if (oldCap >= MAXIMUM_CAPACITY) { threshold = Integer.MAX_VALUE; return oldTab; } // 扩大容量为当前容量的两倍，但不能超过 MAXIMUM_CAPACITY else if ((newCap = oldCap << 1) = DEFAULT_INITIAL_CAPACITY) newThr = oldThr < 0) // initial capacity was placed in threshold newCap = oldThr; // 如果初始化的值为 0，则使用默认的初始化容量 else { // zero initial threshold signifies using defaults newCap = DEFAULT_INITIAL_CAPACITY; newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY); } // 如果新的容量等于 0 if (newThr == 0) { float ft = (float)newCap * loadFactor; newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ? (int)ft : Integer.MAX_VALUE); } threshold = newThr; @SuppressWarnings({"rawtypes","unchecked"}) Node[] newTab = (Node[])new Node[newCap]; // 开始扩容，将新的容量赋值给 table table = newTab; // 原数据不为空，将原数据复制到新 table 中 if (oldTab != null) { // 循环数组，复制非空元素到新 table for (int j = 0; j < oldCap; ++j) { Node 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)e).split(this, newTab, j, oldCap); // 否则为链表，进行链表复制，JDK 1.8 扩容优化部分 else { // preserve order Node loHead = null, loTail = null; Node hiHead = null, hiTail = null; Node next; do { next = e.next; // 原索引 if ((e.hash & oldCap) == 0) { if (loTail == null) loHead = e; else loTail.next = e; loTail = e; } // 原索引 + oldCap 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; } // 将原索引 + oldCap 放到哈希桶中 if (hiTail != null) { hiTail.next = null; newTab[j + oldCap] = hiHead; } } } } } return newTab; }

从以上源码可以看出，JDK1.8在扩容时并没有像JDK1.7那样，重新计算每个元素的哈希值，而是通过高位运算（e.hash&oldCap）来确定元素是否需要移动，比如e的信息如下：

e.hash = 10 0000 1010 oldCap = 16 0001 0000

使用 e.hash & oldCap 得到的结果高一位为 0， 当结果为 0 时 表示元素在扩容时位置不会发生任何变化，第二种情况：

e.hash = 10 0001 1010 oldCap = 16 0001 0000

这样得到的结果高一位为 1 ， 当结果为 1 时， 表示元素在扩容时位置发生了变化， 新的下标位置 = 原下标位置 + 原数组长度。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zxjcqSTC-1584156615907)(C:\Users\14500\AppData\Roaming\Typora\typora-user-images\1584155742994.png)]

其中红色的虚线图代表了扩容时元素移动的位置。

HashMap 死循环分析

以 JDK 1.7 为例，假设 HashMap 默认大小为 2，原本 HashMap 中有一个元素 key(5)，我们再使用两个线程：t1 添加元素 key(3)，t2 添加元素 key(7)，当元素 key(3) 和 key(7) 都添加到 HashMap 中之后，线程 t1 在执行到 Entry next = e.next; 时，交出了 CPU 的使用权， 那么此时线程t1中的e指向了key(3)，而next指向了key(7)；之后线程t2重新rehash之后链表的顺序被反转，链表的位置变成了 key(5) → key(7) → key(3)，其中 “→” 用来表示下一个元素。 当 t1 重新获得执行权之后，先执行 newTalbe[i] = e 把 key(3) 的 next 设置为 key(7)，而下次循环时查询到 key(7) 的 next 元素为 key(3)，于是就形成了 key(3) 和 key(7) 的循环引用，因此就导致了死循环的发生，如下图所示：

当然发生死循环的原因是 JDK 1.7 链表插入方式为首部倒序插入，这个问题在 JDK 1.8 得到了改善，变成了尾部正序插入。 因为 HashMap 本身就是非线程安全的，如果要在多线程下，建议使用 ConcurrentHashMap 替代，

作者：sen47

hashmap