Java集合之深入理解HashMap
1、HashMap底层数据结构
HashMap是Java提供的使用K-V键值对方式进行存储和访问的集合类。其底层实际上是一个“链表散列”的数据结构,即数组和链表的结构,但是在jdk1.8里加入了红黑树的实现,当链表的长度超过8且size达到64时,转换为红黑树的结构,提升查询的性能。
那么为什么采用红黑树而不是平衡二叉树呢?原因是虽然红黑树的查询性能略逊色于AVL(平衡二叉树)树,因为他比AVL树会稍微不平衡最多一层,也就是说红黑树的查询性能只比相同内容的AVL树最多多一次比较,但是,红黑树在插入和删除上比AVL开销小得多。
2、put方法源码分析
put方法整体流程:
1、检查map中的数据Node table[]是否初始化,没有则初始化
2、根据新增的key的hashcode,获取table[(n-1) & hashCode]元素,如果为空,直接放入到此位置
3、如果2上面对应位置的元素不为空,对比新的key.equals(oldKey)是否相等,如果相等,替换就元素的值;如果不相等,判断2中的元素是否是红黑树,如果是,将新元素加入到红黑树结构中,如果不是红黑树结构,将新元素添加到该元素的链表结构中
4、若链表的长度超过8,转为红黑树结构
5、当前HashMap的size+1,并检查当前的容量是否超过初始容量和负载因子的乘积,如果超过,则扩容
// 入口put方法
public V put(K key, V value) {
return putVal(hash(key), key, value, false, true);
}
// 获取对象hash值
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
// 1、table是否初始化,没有则初始化
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
// 2、根据新增的key的hashcode,获取table[(n-1) & hashCode]元素,如果为空,直接放入到此位置
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
//长度超过8,转为红黑树
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();
// 插入数据后的操作,子类实现(LinkedHashMap)
afterNodeInsertion(evict);
return null;
}
3、HashMap避免hash冲突的优化
当key的hash值出现冲突时,会使得不同的数据存放到HashMap数组的同一个位置,形成链表或者红黑树,在此情况下,当需要获取对应的key的值时,查询次数会增加,影响性能,因此要尽量避免出现hash值冲突的情况发生。HashMap主要做了两点优化避免hash冲突。
1、hash寻址算法优化:用与运算替代取模,提升性能
tab[i = (n - 1) & hash])
当n是2的幂值时,hash对n取模的效果 与 hash & (n - 1),效果是一样的,但是后者的性能更高
2、hash计算优化:在计算key对应所在table位置时,是与容量n进行取模运算的。但是n一般情况下不会太大,高16位一般是0,那么在第一步的计算中,hash值只有低16位参与计算,这样会增大hash冲突的概率。因此对每个hash值,在他的低16位中,让高低16位进行了异或,让他的低16位同时保持了高低16位的特征,尽量避免一些hash值后续出现冲突,大家可能会进入数组的同一个位置
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
4、hash冲突后的优化,为什么链表长度超过8就转换成红黑树
当出现hash冲突时,HashMap是先将数据转换成链表。当链表长度超过8且size达到64后,会转换成红黑树。为什么是长度超过8就转换呢?看一下类中的说明:
Because TreeNodes are about twice the size of regular nodes,
we use them only when bins contain enough nodes to warrant use.
翻译一下:因为红黑树的空间占用是常规节点的两倍,所以仅当链表包含足够的节点时,才会使用红黑树。
所以第一点,节点数不能太少,否则空间占用多,不划算。但是链表节点数也不能太多,否则查询效率太低。红黑树的查找时间复杂度是log(n),长度为8,查找长度为log(8)=3,链表的查找时间复杂度为n/2,当长度为8时,平均查找长度为8/2=4,这才有转换成树的必要;链表长度如果是小于等于6,6/2=3,虽然速度也很快的,但是转化为树结构和生成树的时间并不会太短。
网上有说法是泊松分布规律,8的概率已经很低所以才选择8这个数。看一下类说明:
* In usages with well-distributed user hashCodes, tree bins are
* rarely used. 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
翻译一下:
第一句是重点:在hashcode均匀分布的情况下,红黑树基本不会被使用到。为什么呢?后面的话是解释:理想情况下,在随机哈希代码下,当负载因子为0.75时,桶中的节点频率遵循泊松分布,节点长度出现的概率是上面给出的情况,超过8的概率非常非常小,那么转换成红黑树的概率就很小。所以类中提到泊松分布,只是为了解释第一句话以及负载因子默认值取0.75的一个原因而已,跟链表长度超过8再转换红黑树并没有关系。8这个取值其实跟负载因子默认取0.75是一个原因,是空间和时间的折中,应该是数学理论中的知识。
5、HashMap死循环问题
在多线程环境下操作HashMap,JDK1.7中会出现死循环问题。其根本原因是多线程扩容时,链表采用的是头插法,导致链表元素的next指针出现循环引用,在get时出现死循环。在JDK1.8中,扩容操作已经改成了尾插法,但是在多线程环境下还是有其他问题存在,因此要直接使用ConcurrentHashMap,不要使用HashMap。