【jdk源码3】HashMap源码学习
可以毫不夸张的说,HashMap是容器类中用的最频繁的一个,而Java也对它进行优化,在jdk1.7及以前,当将相同Hash值的对象以key的身份放到HashMap中,HashMap的性能将由O(1)下降到O(N),所以jdk1.8将相同Hash值的key以红黑树的形式进行存储。
一、简单理解
1.1 初始容量的设计
给我的感受是,给用户自由,但是要在限定的范围内。
首先介绍初始容量是什么,引用Java API中的介绍:
HashMap 的实例有两个参数影响其性能:初始容量 和加载因子。容量 是哈希表中桶的数量,初始容量只是哈希表在创建时的容量。加载因子 是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时,则要对该哈希表进行 rehash 操作(即重建内部数据结构),从而哈希表将具有大约两倍的桶数。
也就是说,我们可以有远见知道HashMap中将要存入多少数据,而相应的设置初始容量,减少rehash的次数,因为每次rehash将会对HashMap进行一次重构,影响性能,因此HashMap的构造方法中提供了对初始容量的设置:
HashMap(int initialCapacity) :构造一个带指定初始容量和默认加载因子 (0.75) 的空 HashMap。 HashMap(int initialCapacity, float loadFactor) :构造一个带指定初始容量和加载因子的空 HashMap。
但是HashMap在设计的时候,已经考虑到要rehash,以及根据Hash值在固定数量的桶中查询数据,加上对数字的移位运算最高效,所以桶的数量被设计为2的几次方,但是用户输入初始容量是任意的,HashMap是怎么处理的呢?它是取比输入值-1大的且最近的2的几次方的值:
static final int tableSizeFor(int cap) { int n = cap - 1; n |= n >>> 1; n |= n >>> 2; n |= n >>> 4; n |= n >>> 8; n |= n >>> 16; return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; }
也就是说最终初始容量不一定安装你输入的来,就像一开始说的那样,HashMap给你一定的自由,但是不是绝对的自由。
以后写代码也可以这么做,当一个重要属性可能影响效率时,不能给使用者太大的自由度,不然用起来慢就不好了。
1.2 列表转树的条件
首先简单说明下列表和红黑树,对它们有了基本的认识后才能知道为什么决定将列表转成红黑树:
- 所占空间:红黑树>列表
- 性能:红黑树>列表,但是当元素数量特别少时,列表的性能还是大于红黑树的
也就是,有一个阈值,当超过阈值时才会将列表转换成红黑树,为了提高性能HashMap还是考虑的很多的,主要有三个属性涉及到列表和红黑树转换:
static final int TREEIFY_THRESHOLD = 8; static final int UNTREEIFY_THRESHOLD = 6; static final int MIN_TREEIFY_CAPACITY = 64
TREEIFY_THRESHOLD :当一个节点的数量大于此数量的时候,将会将此节点列表转换成一个树。
UNTREEIFY_THRESHOLD :当已经是一个树的节点,在移除元素的时候,如果移除后小于这个值,则将树转换成列表。
MIN_TREEIFY_CAPACITY :当一个节点准备转换成树之前,如果HashMap桶的数量小于此,则不进行转换,而是将HashMap进行扩容。
也就是说为了一个优化,相当于将HashMap一半的代码进行了重新,为了提升当元素都放置到一个桶时性能的下降。但是对于用户来说是透明的,用户在使用上完全感受不到变化,所以说优化是没有终点的,这一点我还是挺佩服他们的。
1.3 元素的大小比较
之前讲TreeMap的时候说过,放入TreeMap的key必须具备可比较性,要么本身实现Comparable接口,要么传入key的比较器,因为如果key不能比较大小,就没办法构建一棵树。而我们在放入HashMap的key时,却没有对此有要求,它是怎么实现的呢。
首先判断key的类型是否是Comparable,如果是,就通过自身的比较方法进行比较。
如果key不是Comparable,那么就通过key本身的Hash值进行比较,即便子类重写了hashCode方法,也会用最原始的,实际上是用了System的一个方法:
System.identityHashCode(Object x)
这个方法,返回给定对象的哈希码,该代码与默认的方法 hashCode() 返回的代码一样,无论给定对象的类是否重写 hashCode()。
也就是说最终总是能比较出大小,当然如果还一样,说明key是一样的,覆盖即可。
其中判断key的类型是否是Comparable中有一段代码如下:
static Class<?> comparableClassFor(Object x) { if (x instanceof Comparable) { Class<?> c; Type[] ts, as; Type t; ParameterizedType p; if ((c = x.getClass()) == String.class) // bypass checks return c; if ((ts = c.getGenericInterfaces()) != null) { for (int i = 0; i < ts.length; ++i) { if (((t = ts[i]) instanceof ParameterizedType) && ((p = (ParameterizedType)t).getRawType() == Comparable.class) && (as = p.getActualTypeArguments()) != null && as.length == 1 && as[0] == c) // type arg is c return c; } } } return null; }
说实话我一开始没有想到会这么复杂,后来我认真研究了一下发现一个类即便实现了Comparable接口,也有可能比较的是其他类:
class Dog implements Comparable<Object>{ public String name; public Dog(String name) { this.name = name; } @Override public int compareTo(Object o) { // TODO Auto-generated method stub return 0; } }
没想到判断的这么严谨,因为印象中很少有类实现Comparable接口,而不去比较自己的,简单总结它的逻辑:
- 首先是一个Comparable
- Comparable必须是一个参数化类型,就是说指定比较类型
- 参数化有一个参数,且是它本身
看完这部分,我想了想TreeMap为什么没有借鉴HashMap的这种方式,而必须让key具有比较性,原因其实很简单,HashMap的作用就是存储快速读取,而TreeMap的额外多了个目的就是排序,如果一个key不具备可比较性,而最终使用了最原始的hashCode,那排序就没有了意义,还不如使用更高效的HashMap呢。
二、问题及总结
HashMap做为最常用的容器类,Java已经封装的足够好了,而我们使用的时候如果能做到以下两点也就能最大化的提高HashMap的性能:
- 自定义对象做为key时,重写hashCode和equals方法
- 如果能预见存入HashMap元素的数量,在初始化的时候指定
其它暂时没有遇到什么问题。