关于JDK1.7+中HashMap对红黑树场景的思考

背景

在1.7之前的版本,当数组元素较多(几百、几千,或者更多)的时候,在这种前提扩容,涉及全量元素的遍历和坐标的重新定位,这个耗时会比较长。这是之前存在的一个弊端吧。那么引入红黑树之后就解决了问题,那是怎么解决的呢,我说下自己的理解。

过程分析

既然数组扩容导致了变慢,那就是从扩容方向思考,谁决定了扩容呢?负载因子和数组长度。数组长度是resize自动做的,所以对用户来讲这应该是一个关注不到的变量,那就只剩负载因子了。负载因子越大,扩容的频率就越低。

1. 负载因子较小(小于1)

hash碰撞几率小,当数组元素链表长度达到8个的时候才会转成红黑树,满足这种条件的应该很极端很极端了,与JDK1.7之前的差异其实不大,存在扩容时卡顿。

2. 负载因子较大(大于1)

hash碰撞几率大,所以一个数组元素出现红黑树的几率变大,每个树的数量也会很多。因为扩容的阈值调的比较大,导致轻易不会扩容,整个hashmap更偏向与一颗颗红黑树。扩容就可以理解为对红黑树的维护,达到了丝般顺滑的效果。

总结

根据前面的分析,引入红黑树主要好处有2个:

  1. 极端情况下,保证hashmap碰撞过多的元素的高性能操作。
  2. 负载因子变大情况,使hashmap倾向于一个红黑树的数组,带来的好处就是对元素的操作时间复杂度的整体稳定。

本质上还是得具体场景的权衡,如果数组太大,扩容会导致外部调用超时那就选择调大负载因子,达到削峰的目的。否则维持以前的用法就可以了,
完。

posted @ 2019-01-23 17:50  土豆条  阅读(459)  评论(0编辑  收藏