高性能场景下，HashMap的优化使用建议

关注

转载最新推荐文章于 2026-04-05 02:16:02 发布 1k 阅读 AI 写同款· GEO 优化 ›

ElasticSearch内容分享（八）：ES大厂实践 - 哈啰、腾讯、美团最近十年，Elasticsearch 已经成为了最受欢迎的开源检索引擎，其作为离线数仓、近线检索、B端检索的经典基建，已沉淀了大量的实践案例及优化总结。然而在高并发、高可用、大数据量的 C 端场景，目前可参考的资料并不多。因此，我们希望通过分享在外卖搜索场景下的优化实践，能为大家提供 Elasticsearch 优化思路上的一些借鉴。美团在外卖搜索业务场景中大规模地使用了 Elasticsearch 作为底层检索引擎。其在过去几年很好地支持了外卖每天十亿以上的检索流量。阅读详情

1. HashMap 在JDK 7 与 JDK8 下的差别

顺便理一下HashMap.get(Object key)的几个关键步骤，作为后面讨论的基础。

1.1 获取key的HashCode并二次加工

因为对原Key的hashCode质量没信心，怕会存在大量冲突，HashMap进行了二次加工。

JDK7的做法：

h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);

JDK8 因为对自己改造过的哈希大量冲突时的红黑树有信心，所以简单一些，只是把高16位异或下来。

return h ^ (h >>> 16);

所以即使Key比较均匀无哈希冲突，JDK8也比JDK7略快的原因大概于此。

顺便科普一下，Integer的HashCode就是自己，Long要把高32位异或下来变成int， String则是循环累计结果＊31＋下一个字符，不过因为String是不可变对象，所以生成完一次就会自己cache起来。

1.2 落桶

index = hash & (array.length-1);

桶数组大小是2的指数的好处，通过一次&就够了，而不是代价稍大的取模。

1.3 最后选择Entry

判断Entry是否符合，都是首先哈希值要相等，但因为哈希值不是唯一的，所以还要对比key是否相等，最好是同一个对象，能用＝＝对比，否则要走equals()。比如String，如果不是同一个对象，equals()起来要一个个字符做比较也是挺累的。

if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
return e.value;

更累的是存在哈希冲突的情况，比如两个哈希值取模后落在同一个桶上，或者两条不同的key有相同的哈希值。
JDK7的做法是建一条链表，后插入的元素在上面，一个个地执行上面的判断。
而JDK8则在链表长度达到8，而且桶数量达到64时，建一棵红黑树，解决严重冲突时的性能问题。

2. 很多人忽视的加载因子Load Factor

加载因子存在的原因，还是因为减缓哈希冲突，如果初始桶为16，等到满16个元素才扩容，某些桶里可能就有不止一个元素了。所以加载因子默认为0.75，也就是说大小为16的HashMap，到了第13个元素，就会扩容成32。

2.1 考虑加载因子地设定初始大小

相比扩容时只是System.arraycopy()的ArrayList，HashMap扩容的代价其实蛮大的，首先，要生成一个新的桶数组，然后要把所有元素都重新Hash落桶一次，几乎等于重新执行了一次所有元素的put。

所以如果你心目中有明确的Map 大小，设定时一定要考虑加载因子的存在。

Map map = new HashMap(srcMap.size())这样的写法肯定是不对的，有25%的可能会遇上扩容。

Thrift里的做法比较粗暴， Map map = new HashMap( 2* srcMap.size()), 直接两倍又有点浪费空间。

Guava的做法则是加上如下计算

(int) ((float) expectedSize / 0.75F + 1.0F);

2.2 减小加载因子

在构造函数里，设定加载因子是0.5甚至0.25。
如果你的Map是一个长期存在而不是每次动态生成的，而里面的key又是没法预估的，那可以适当加大初始大小，同时减少加载因子，降低冲突的机率。毕竟如果是长期存在的map，浪费点数组大小不算啥，降低冲突概率，减少比较的次数更重要。

3. Key的设计

对于String型的Key，如果无法保证无冲突而且能用==来对比，那就尽量搞短点，否则一个个字符的equals还是花时间的。

甚至，对于已知的预定义Key，可以自己试着放一下，看冲不冲突。比如，像”a1”,”a2”,”a3” 这种，hashCode是个小数字递增，绝对是不冲突的：）

4. EnumMap

对于上面的问题，有些同学可能会很冲动的想，这么麻烦，我还是换回用数组，然后用常量来定义一些下标算了。其实不用自己来，EnumMap就是可读性与性能俱佳的实现。

EnumMap的原理是，在构造函数里要传入枚举类，那它就构建一个与枚举的所有值等大的数组，按Enum. ordinal()下标来访问数组，不就是你刚才想做的事情么？

美中不足的是，因为要实现Map接口，而 V get(Object key)中key是Object而不是泛型K，所以安全起见，EnumMap每次访问都要先对Key进行类型判断。在JMC里录得不低的采样命中频率。
所以也可以自己再port一个类出来，不实现Map接口，或者自己增加fastGet(),fastPut()的函数。