HashMap实际上是一个数组,数组里面的每个元素都是一个链表。每个元素在通过put方法放入HashMap中的时候,要按照如下步骤进行:
1.根据该元素自身提供的hashcode计算出散列值,该散列值就是数组的下标
2.将新元素放入该数组位置的链表中
先来看一下数组的定义:
这是一个数组,transient关键字告诉我们它不会参与序列化。既然是一个数组,总有数目上限,也就意味着如果存入HashMap的元素太多,导致数组大小不能够存放所有的链表的时候,数组大小必须要能够调整。所以首先来考察一下数组容量的相关算法。
第一,Entry是什么类型?
这是一个HashMap类的内部静态类。实现了Map.Entry接口。接受两个模板参数K和V。key和hash一旦在构造函数中被初始化,就不可改变,并且由于有next的存在,Entry可以构成一个单向链表。
比较重要的是equals和hashCode方法。代码先列出来,后面再解释。
第二,初始容量的设定
大多数都在下面的构造函数里面.用于指定的initialCapacity不准小于0,也不能超过最大值。并且最终的capicity必须是2的n次方。还有如果使用了无参数的构造函数,默认会创建一个拥有16个元素的数组。
第三,什么时候应该调整数组的大小?
算法是这样,有一个变量size保存了实际数组已经使用了多少个元素,并且如果size的值达到了变量threshold的值,就必须扩充数组的容量。threshold=capicity*loadFactor.capicity是数组最大的容纳元素个数,loadFactor可以在构造函数中制定,否则采用默认值0.75f。capicity的最大值是1<<30(也就是2的30次方,1073741824).由此我们可以看到HashMap最多存放10亿多个链表。
第四,如何调整数组大小?
答案是2倍,很像C++里面的vector的分配策略。
第五,为什么数组大小必须是2的倍数?
散列计算就是计算元素应该放在数组的哪个元素里。准确的说是放到哪个链表里面。按照Java的规则,如果你要想将一个对象放入HashMap中,你的对象的类必须提供hashcode方法,返回一个整数值。比如String类就有如下方法:
注意上面的for循环,有点搞吧?我来举个例子,让你很容易明白它在搞什么名堂。比如有一个字符串“abcde”,采用31进制的计算方法来计算这个字符串的总和,你会写出下面的计算式子:
a*31^4+b*31^3+c*31^2+d*31^1+e*31^0.注意,这里的a,b,c,d或者e指的是它们的ASCII值。很有趣的循环,居然可以用来算N进制。这个循环可以抽出来单独作为计算进制的好工具:
静态方法caculate接受radix作为进制基数,数组a模拟要计算的进制的数字,只是注意表面顺序需要一致。比如 01 二进制串,在数组中要按照{0,1}排列。上面的输出结果是1,符合01的真实值。
那么为什么选用31作为基数呢?先要明白为什么需要HashCode.每个对象根据值计算HashCode,这个code大小虽然不奢求必须唯一(因为这样通常计算会非常慢),但是要尽可能的不要重复,因此基数要尽量的大。另外,31*N可以被编译器优化为
左移5位后减1,有较高的性能。其实选用31还是有争议,反对者(参考 http://stackoverflow.com/questions/299304/why-does-javas-hashcode-in-string-use-31-as-a-multiplier)
认为这个东西还是会导致较多的重复,应该用更大的数字。所以,或许将来Java的实现中会有所变化。下面这篇文章介绍了两个结论:
1.基数要用质数
质数的特性(只有1和自己是因子)能够使得它和其他数相乘后得到的结果比其他方式更容易产成唯一性,也就是hash code值的冲突概率最小。
2.选择31是观测分布结果后的一个选择,不清楚原因,但的确有利。
http://computinglife.wordpress.com/2008/11/20/why-do-hash-functions-use-prime-numbers/
另外,String.hashCode内部会缓存第一次计算的值,因为这是一个final(不可变)类,也就是String对象的内容是不会变的。这能够在多次put到HashMap的场合提高性能,不过似乎用处不多。
现在,有了hash code,来考虑如何计算放入数组的位置。hash code值通常会很大,但是数组的大小有限,默认只有16,大的也不能超过2的30次方。所以,用模运算来保证在数组大小范围内是合理的,比如:index = hash code % array size.不过这有点慢,JDK采用了更快的算法。这个更快的算法源于一个数学规律,就是如果size是2的N次方,那么数X对size的模运算结果等价于X和size-1的按位与运算,也就是 X % size <=> X & (size -1).按位与只消耗一个CPU周期,当然快多了。现在就可理解为什么要故意把数组大小弄成2的N次方了。再回头看一开始计算数组大小的代码,完全理解了。
比如size=16,二进制表示如下:(32位)
0000000000000000000000000010000
size-1=15,表示如下:
0000000000000000000000000001111
假如hash code=4
0000000000000000000000000000100
4 & 15 结果为:
0000000000000000000000000000100
假如hash code=6
0000000000000000000000000000101
6 & 15 结果为:
0000000000000000000000000000101
假如hash code=38
0000000000000000000000000100110
38 & 15 结果为:
0000000000000000000000000000110
通过观察这三个例子,又可以发现一个特点,也就是X & size-1 的结果受到了size的阶数的限制,这里size=16,阶数为4.结果就是只用低4位的1和X按位与,而X的高位没有用到。这会导致重复率相当高。如果用一个算法将X的低位重新计算,比如根据所有位的值进行重新计算,就可以使得hash值分布更均匀。下面的代码揭示了在真正按位与之前,调用了hash函数,进行了一堆位运算。至于为什么用这个算法,我也不知道其来历。不过这里一篇帖子演示了这个hash函数会导致bit的随机性,可以作为理解的开始。
http://stackoverflow.com/questions/9335169/understanding-strange-java-hash-function
上面的for循环是查找并替换符合条件的对象,如果找不到,则添加新的对象。查找到的条件(必须都满足)是:
1.hash值相等
2.key的引用相同或者key的值相等。
获取元素
有了前面的分析,获取元素的逻辑就非常清晰。首先,调用者传递key,从key的hashCode方法获得值后,调用hash函数做一些低位置换,保证hash值的均匀分布,之后和size-1按位与后得到数组的位置。然后取出对应位置的链表,遍历该链表,查找hash值相等,并且key的引用或者值相等的对象,然后返回。代码见下面:
算法时间复杂度平均是O(1),如果hash code很糟糕,让其退化成链表,则是O(N).即便是O(1),也要注意,实际上计算hash用了好几步,绝对比直接从数组中获取某个元素的O(1)时间要长的多。
内存消耗
有一个很好的工具,可以帮助我们检查Java对象内存的消耗。从这里下载jar包:http://sizeof.sourceforge.net/
解压后将SizeOf.jar复制到某个目录,比如我的/home/chenshu,在项目中加入这个jar包,并且设置JVM参数:-javaagent:/home/chenshu/SizeOf.jar。
这个类库提供了一些静态函数,利用java.lang.Instrument的Instrumentation.getObjectSize(),能够计算Java对象真正在虚拟机里面占用的内存大小。下面的代码创建了一个只保存一个对象的HashMap,并计算内存占用。
因此,在大数据量(个人认为超过1万),并且需要快速查找和插入的时候,HashMap是非常好的选择。但是如果数据量不大的情况下,以tree实现的Map也是一个不错的选择,毕竟节省很多内存。而且tree还可以实现set这样的数据结构,有时候比Map更符合我们的需求。
如果你现在拿起来就不假思索的使用HashMap(我知道这样的程序员太多了),请慎重。因为让你变得平凡的并不是项目进度紧或者工资低,而是对自己的要求不够高。