JDK1.8 HashMap 源码分析详解(5)

加载因子存在的原因，还是因为要减缓哈希冲突，例如：默认初始桶为16，或等到满16个元素才扩容，某些桶里可能就会有多个元素了。所以加载因子默认为0.75，也就是说大小为16的HashMap，扩容临界值threshold=0.75*16=12,到了第13个元素，就会扩容成32。

6.2 加载因子减小？

在构造函数里，设定小一点的加载因子,比如0.5，甚至0.25。
若是一个长期存在的Map,并且key不固定，那可以适当加大初始大小，同时减少加载因子，降低冲突的机率，也能减少寻址的时间。用空间来换时间，这时也是值得的。

6.3 初始化时是否定义容量？

通过以上源码分析，每次扩容都需要重创建桶数组、链表、数据转换等，所以扩容成本还是挺高的，若初始化时能设置准确或预估出需要的容量，即使大一点，用空间来换时间，有时也是值得的。

6.4 String型的Key设计优化？

如果无法保证无冲突而且能用==来对比，那就尽量搞短点，试想一个个字符的equals都是需要花时间的。顺序型的Key,如：k1、k2、k3...k50,这种key的hashCode是数字递增，冲突的可能性实在太小。

for(int i=0;i<100;i++){ System.out.println(key+".hashCode="+key.hashCode()); } 结果： K0.hashCode = 2373 K1.hashCode = 2374 K2.hashCode = 2375 K3.hashCode = 2376 K4.hashCode = 2377 ... ...

本文永久更新链接地址：