一、存储结构-字段
这里需要讲明白两个问题:数据底层具体存储的是什么?这样的存储方式有什么优点呢?
在理解Hash和扩容流程之前,我们得先了解下HashMap的几个字段。从HashMap的默认构造函数源码可知,构造函数就是对下面几个字段进行初始化,源码如下:
int threshold; // 所能容纳的key-value对极限
final float loadFactor; // 负载因子
int modCount; // 用于迭代的快速失败
int size; // HashMap中实际存在的键值对数量
//threshold
//就是在Loadfactor和length(table长度)对应下允许的最大元素数目
threshold = length * loadFactor
- Node[] table的初始化长度length(默认值是16)
- Load factor为负载因子(默认值是0.75)
- threshold是HashMap所能容纳的最大数据量的Node(键值对)个数。threshold就是在此Load factor和length(数组长度)对应下允许的最大元素数目,超过这个数目就重新resize(扩容),扩容后的HashMap容量是之前容量的两倍。
- modCount字段主要用来记录HashMap内部结构发生变化的次数,主要用于迭代的快速失败。参考这篇:快速失败和安全失败的区别
这里存在一个问题,出现拉链过长的情况,会严重影响HashMap的性能。于是,在JDK1.8版本中,对数据结构做了进一步的优化,引入了红黑树。而当链表长度太长(默认超过8)时,链表就转换为红黑树,利用红黑树快速增删改查的特点提高HashMap的性能。
二、功能实现-方法
1. 确定哈希桶数组索引位置
方法一:
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); //第三步 取模运算
}
这里的Hash算法本质上就是三步:取key的hashCode值、高位运算、取模运算。
1、取key的hashCode值:h = k.hashCode()
2、高位运算的算法:h = k.hashCode()) ^ (h >>> 16)
通过hashCode()的高16位异或低16位实现的。在JDK1.8的实现中,优化了高位运算的算法。这么做可以在数组table的length比较小的时候,也能保证考虑到高低Bit都参与到Hash的计算中,同时不会有太大的开销。
3、得到该对象的保存位:h & (table.length -1)
当length总是2的n次方时,length-1的前n位二进制位全为1(见图中) h& (length-1)运算等价于对length取模,也就是h%length,但是&比%具有更高的效率。 HashMap底层数组的长度总是2的n次方,这是HashMap在速度上的优化。
2、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;
// 如果map还是空的,则先开始初始化,table是map中用于存放索引的表
if ((tab = table) == null || (n = tab.length) == 0) {
n = (tab = resize()).length;
}
// 使用hash与数组长度减一的值进行异或得到分散的数组下标,预示着按照计算现在的
// key会存放到这个位置上,如果这个位置上没有值,那么直接新建k-v节点存放
// 其中长度n是一个2的幂次数
if ((p = tab[i = (n - 1) & hash]) == null) {
tab[i] = newNode(hash, key, value, null);
}
// 如果走到else这一步,说明key索引到的数组位置上已经存在内容,即出现了碰撞
// 这个时候需要更为复杂处理碰撞的方式来处理,如链表和树
else {
Node<K,V> e; K k;
// 其中p已经在上面通过计算索引找到了,即发生碰撞那一个节点
// 比较,如果该节点的hash和当前的hash相等,而且key也相等或者
// 在key不等于null的情况下key的内容也相等,则说明两个key是
// 一样的,则将当前节点p用临时节点e保存
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k)))) {
e = p;
}
// 如果当前节点p是(红黑)树类型的节点,则需要特殊处理
// 如果是树,则说明碰撞已经开始用树来处理,后续的数据结构都是树而非
// 列表了
else if (p instanceof TreeNode) {
// 其中this表示当前HashMap, tab为map中的数组
e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
}
else {
//遍历碰撞链表
for (int binCount = 0; ; ++binCount) {
// 1、如果当前碰撞到的节点没有后续节点,则直接新建节点并追加
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
// TREEIFY_THRESHOLD = 8
// 从0开始的,如果到了7则说明满8了,这个时候就需要转
// 重新确定是否是扩容还是转用红黑树了
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
treeifyBin(tab, hash);
break;
}
///2、找到了碰撞节点中,key完全相等的节点,则用新节点替换老节点
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
break;
//3、继续遍历
p = e;
}
}
// 此时的e是保存的被碰撞的那个节点,即老节点
if (e != null) { // existing mapping for key
V oldValue = e.value;
// onlyIfAbsent是方法的调用参数,表示是否替换已存在的值,
// 在默认的put方法中这个值是false,所以这里会用新值替换旧值
if (!onlyIfAbsent || oldValue == null)
e.value = value;
// Callbacks to allow LinkedHashMap post-actions
afterNodeAccess(e);
return oldValue;
}
}
// map变更性操作计数器
// 比如map结构化的变更像内容增减或者rehash,这将直接导致外部map的并发
// 迭代引起fail-fast问题,该值就是比较的基础
++modCount;
// size即map中包括k-v数量的多少
// 当map中的内容大小已经触及到扩容阈值时,则需要扩容了
if (++size > threshold)
resize();
// Callbacks to allow LinkedHashMap post-actions
afterNodeInsertion(evict);
return null;
}
这里有一张来自其他博客的HashMap流程图,非常清晰,结合代码阅读,帮助理解。
3、扩容
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);
下面我们讲解下JDK1.8做了哪些优化。经过观测可以发现,我们使用的是2次幂的扩展(指长度扩为原来2倍),所以,元素的位置要么是在原位置,要么是在原位置再移动2次幂的位置。
看下图可以明白这句话的意思,n为table的长度,图(a)表示扩容前的key1和key2两种key确定索引位置的示例,图(b)表示扩容后key1和key2两种key确定索引位置的示例,其中hash1是key1对应的哈希与高位运算结果。
因此,我们在扩充HashMap的时候,不需要像JDK1.7的实现那样重新计算hash,只需要看看原来的hash值新增的那个bit是1还是0就好了,是0的话索引没变,是1的话索引变成“原索引+oldCap”,可以看看下图为16扩充为32的resize示意图:
这个设计确实非常的巧妙,既省去了重新计算hash值的时间,而且同时,由于新增的1bit是0还是1可以认为是随机的,因此resize的过程,均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。
小结
(1) 扩容是一个特别耗性能的操作,所以当程序员在使用HashMap的时候,估算map的大小,初始化的时候给一个大致的数值,避免map进行频繁的扩容。
(2) 负载因子是可以修改的,也可以大于1,但是建议不要轻易修改,除非情况非常特殊。
(3) HashMap是线程不安全的,不要在并发的环境中同时操作HashMap,建议使用ConcurrentHashMap。
(4) JDK1.8引入红黑树大程度优化了HashMap的性能。