一 概述
深入理解Java集合中的源代码,可以帮助我们更好地了解大佬的意图,规避不必要的bug。
源码中的一段注释,提取关键信息
Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key. (The HashMap class is roughly equivalent to Hashtable, except that it is unsynchronized and permits nulls.) This class makes no guarantees as to the order of the map; in particular, it does not guarantee that the order will remain constant over time.
大致意思是:这个哈希表是基于 Map 接口的实现的,它允许 null 值和 null 键,它不是线程同步的,同时也不保证有序。
This implementation provides constant-time performance for the basic operations (get and put), assuming the hash function disperses the elements properly among the buckets. Iteration over collection views requires time proportional to the “capacity” of the HashMap instance (the number of buckets) plus its size (the number of key-value mappings). Thus, it’s very important not to set the initial capacity too high (or the load factor too low) if iteration performance is important. An instance of HashMap has two parameters that affect its performance: initial capacity and load factor. The capacity is the number of buckets in the hash table, and the initial capacity is simply the capacity at the time the hash table is created. The load factor is a measure of how full the hash table is allowed to get before its capacity is automatically increased. When the number of entries in the hash table exceeds the product of the load factor and the current capacity, the hash table is rehashed (that is, internal data structures are rebuilt) so that the hash table has approximately twice the number of buckets.
大意:讲的是 Map 的这种实现方式为 get (取)和 put(存)带来了比较好的性能。但是如果涉及到大量的遍历操作的话,就 尽量不要把 capacity 设置得太高(或 load factor 设置得太低),否则会严重降低遍历的效率。
影响 HashMap 性能的两个重要参数:“initial capacity”(初始化容量)和”load factor“(负载因子)。简单来说,容量就是哈希表桶的个数,负载因子就是键值对 个数与哈希表长度的一个比值,当比值超过负载因子之后,HashMap 就会进行 rehash 操作来进行扩容。
HashMap 的大致结构如下图所示,其中哈希表是一个数组,我们经常把数组中的每 一个节点称为一个桶,哈希表中的每个节点都用来存储一个键值对。在插入元素时, 如果发生冲突(即多个键值对映射到同一个桶上)的话,就会通过链表的形式来解 决冲突。因为一个桶上可能存在多个键值对,所以在查找的时候,会先通过 key 的
哈希值先定位到桶,再遍历桶上的所有键值对,找出 key 相等的键值对,从而来获 取 value。
二 属性
1 | //默认的初始容量为 16 |
Node 类的定义,它是 HashMap 中的一个静态内部类,哈希表中的每一个 节点都是 Node 类型。我们可以看到,Node 类中有 4 个属性,其中除了 key 和 value 之外,还有 hash 和 next 两个属性。hash 是用来存储 key 的哈希值的,next 是在构建链表时用来指向后继节点的。
1 | static class Node<K,V> implements Map.Entry<K,V> { |
三方法
1 get方法
1 | //get 方法主要调用的是 getNode 方法,所以重点要看 getNode 方法的 |
实现步骤大致如下:
- 通过 hash 值获取该 key 映射到的桶。
- 桶上的 key 就是要查找的 key,则直接命中。
- 桶上的 key 不是要查找的 key,则查看后续节点:
(1)如果后续节点是树节点,通过调用树的方法查找该 key。
(2)如果后续节点是链式节点,则通过循环遍历链查找该 key。
2 put方法
1 | //put 方法的具体实现也是在 putVal 方法中,所以我们重点看下面的 putVal 方法 |
put 方法比较复杂,实现步骤大致如下:
- 先通过 hash 值计算出 key 映射到哪个桶。
- 如果桶上没有碰撞冲突,则直接插入。
- 如果出现碰撞冲突了,则需要处理冲突:
(1)如果该桶使用红黑树处理冲突,则调用红黑树的方法插入。
(2)否则采用传统的链式方法插入。如果链的长度到达临界值,则把链转变为红 黑树。 - 如果桶中存在重复的键,则为该键替换新值。
- 如果 size 大于阈值,则进行扩容。
3 remove方法
1 | //remove 方法的具体实现在 removeNode 方法中,所以我们重点看下面的 removeNode 方法 |
5 Hash方法
在get方法和put方法中都需要先计算key映射到哪个桶上,然后才进行之后的操作, 计算的主要代码如下:
1 | (n - 1) & hash |
上面代码中的 n 指的是哈希表的大小,hash 指的是 key 的哈希值,hash 是通过下面 这个方法计算出来的,采用了二次哈希的方式,其中 key 的 hashCode 方法是一个 native 方法:
1 | static final int hash(Object key) { |
这个 hash 方法先通过 key 的 hashCode 方法获取一个哈希值,再拿这个哈希值与它 的高 16 位的哈希值做一个异或操作来得到最后的哈希值,计算过程可以参考下图。 为啥要这样做呢?注释中是这样解释的:如果当 n 很小,假设为 64 的话,那么 n-1 即为 63(0x111111),这样的值跟 hashCode()直接做与操作,实际上只使用了哈希 值的后 6 位。如果当哈希值的高位变化很大,低位变化很小,这样就很容易造成冲 突了,所以这里把高低位都利用起来,从而解决了这个问题。
正是因为与的这个操作,决定了 HashMap 的大小只能是 2 的幂次方,想一想,如果 不是2的幂次方,会发生什么事情?即使你在创建HashMap的时候指定了初始大小, HashMap 在构建的时候也会调用下面这个方法来调整大小:
1 | static final int tableSizeFor(int cap) { |
这个方法的作用看起来可能不是很直观,它的实际作用就是把 cap 变成第一个大于 等于 2 的幂次方的数。例如,16 还是 16,13 就会调整为 16,17 就会调整为 32。
5 resize方法
HashMap 在进行扩容时,使用的 rehash 方式非常巧妙,因为每次扩容都是翻倍,与 原来计算(n-1)&hash 的结果相比,只是多了一个 bit 位,所以节点要么就在原来 的位置,要么就被分配到“原位置+旧容量”这个位置。
例如,原来的容量为 32,那么应该拿 hash 跟 31(0x11111)做与操作;在扩容扩到 了 64 的容量之后,应该拿 hash 跟 63(0x111111)做与操作。新容量跟原来相比只 是多了一个 bit 位,假设原来的位置在 23,那么当新增的那个 bit 位的计算结果为 0 时,那么该节点还是在 23;相反,计算结果为 1 时,则该节点会被分配到 23+31 的 桶上。
正是因为这样巧妙的 rehash 方式,保证了 rehash 之后每个桶上的节点数必定小于等 于原来桶上的节点数,即保证了 rehash 之后不会出现更严重的冲突。
1 | final Node<K,V>[] resize() { |
在这里有一个需要注意的地方,有些文章指出当哈希表的桶占用超过阈值时就进行 扩容,这是不对的;实际上是当哈希表中的键值对个数超过阈值时,才进行扩容的.
四 总结
通过红黑树的方式来处理哈希冲突是我第一次看见!学过哈希,学过红黑树,从来没有想过两个可以结合到一起这么用,或许这就是大佬吧!!!
按照原来的拉链法来解决冲突,如果一个桶上的冲突很严重的话,是会导致哈希表 的效率降低至 O(n),而通过红黑树的方式,可以把效率改进至 O(logn)。相比 链式结构的节点,树型结构的节点会占用比较多的空间,所以这是一种以空间换时间的改进方式。