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

背景

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

过程分析

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

1. 负载因子较小（小于1）

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

2. 负载因子较大（大于1）

hash碰撞概率大，因此一个数组元素出现红黑树的概率变大，每一个树的数量也会不少。由于扩容的阈值调的比较大，致使轻易不会扩容，整个hashmap更偏向与一颗颗红黑树。扩容就能够理解为对红黑树的维护，达到了丝般顺滑的效果。

总结

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

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

本质上仍是得具体场景的权衡，若是数组太大，扩容会致使外部调用超时那就选择调大负载因子，达到削峰的目的。不然维持之前的用法就能够了，
完。