源码阅读
-
HashMap源码中有六个重要属性
- 初始化长度为16:
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4;
- 最大长度为1073741824:
static final int MAXIMUM_CAPACITY = 1 << 30;
- 默认的加载因子0.75:
static final float DEFAULT_LOAD_FACTOR = 0.75f;
- 扩容红黑树条件(当链表长度大于8且容量大于64):
static final int TREEIFY_THRESHOLD = 8;
- 扩容红黑树条件(当元素小于6时):
static final int UNTREEIFY_THRESHOLD = 6;
- 最小树容量:
static final int MIN_TREEIFY_CAPACITY =
- 初始化长度为16:
-
查询:Hash冲突时,需要判断key值是否相等
public V get(Object key) { Node<K,V> e; // 对 key 进行哈希操作 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) { // 如果第一节点是树结构,则使用 getTreeNode 直接获取相应的数据 if (first instanceof TreeNode) return ((TreeNode<K,V>)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; }
-
新增
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<K,V>[] tab; Node<K,V> 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,则直接插入 tab[i] = newNode(hash, key, value, null); else { Node<K,V> 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<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); // 转换为红黑树进行处理 链表长度大于等于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; }
-
扩容
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; } // 扩大容量为当前容量的两倍,但不能超过 MAXIMUM_CAPACITY 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 // 如果初始化的值为 0,则使用默认的初始化容量 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<K,V>[] newTab = (Node<K,V>[])new Node[newCap]; // 开始扩容,将新的容量赋值给 table table = newTab; // 原数据不为空,将原数据复制到新 table 中 if (oldTab != null) { // 根据容量循环数组,复制非空元素到新 table 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 { // preserve order // 链表复制,JDK 1.8 扩容优化部分 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; } // 原索引 + 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; }
-
HashMap在扩容上,JDK1.7是重新计算每个元素的哈希值,而JDK1.8直接通过高位运算
(e.hash & oldCap)
来确定元素是否移动,key1的信息如下:- key1.hash = 10 0000 1010
- oldCap = 16 0001 0000
使用
e.hash & oldCap
得到的结果,高一位为 0,当结果为 0 时表示元素在扩容时位置不会发生任何变化,而 key 2 信息如下:- key2.hash = 10 0001 0001
- oldCap = 16 0001 0000
这时候得到的结果,高一位为 1,当结果为 1 时,表示元素在扩容时位置发生了变化,新的下标位置等于原下标位置 + 原数组长度
-
-
HashMap死循环
在JDK1.7中,假设 HashMap 默认大小为 2,原本 HashMap 中有一个元素 key(5),我们再使用两个线程:t1 添加元素 key(3),t2 添加元素 key(7),当元素 key(3) 和 key(7) 都添加到 HashMap 中之后,线程 t1 在执行到
Entry<K,V> next = e.next;
时,交出了 CPU 的使用权void transfer(Entry[] newTable, boolean rehash) { int newCapacity = newTable.length; for (Entry<K,V> e : table) { while(null != e) { Entry<K,V> next = e.next; // 线程一执行此处 if (rehash) { e.hash = null == e.key ? 0 : hash(e.key); } int i = indexFor(e.hash, newCapacity); e.next = newTable[i]; newTable[i] = e; e = next; } } }
那么此时线程 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
面试题
1. HashMap 底层是如何实现的?在 JDK 1.8 中它都做了哪些优化
在JDK1.7中HashMap是以数组➕链表的形式组成
JDK1.8之后新增了红黑树的组成结构,当链表长度大于8且容量大于64时,链表结构会转换成红黑树结构
而之所以添加红黑树是因为,一旦链表过长,会严重影响HashMap的性能,而红黑树具有快速增删改查的特点
2. 为什么加载因子时0.75?
加载因子也叫扩容因子,即用来判断何时扩容,现源码中加载因子为0.75,故,若初始化长度为16,则当HashMap中有16*0.75=12个元素时,HashMap就会扩容
为什么加载因子时0.75?,主要是出于容量与性能之间的考虑
- 若加载因子设置较小,扩容门槛变低,故会占用更多的空间,此时元素的存储较为稀疏,发生Hash冲突的可能性较小,故,操作性能较高
- 若加载因子设置较大,扩容门槛提高,扩容发生频率较低,占用空间较小,但此时会发生Hash冲突的概率提高,故,需要更复杂的数据结果来存储元素,这样对元素的操作时间就会增加,运行效率降低
- HashMap的容量(capacity)有一个固定的要求,必须为2的幂,所以负载因子为0.75时,
capacity * 0.75
的乘积结果为一个整数
所以综合考虑,选择了0.75来做为加载因子