背景
在1.7之前的版本，当数组元素较多（几百、几千，或者更多）的时候，在这种前提扩容，涉及全量元素的遍历和坐标的重新定位，这个耗时会比较长。这是之前存在的一个弊端吧。那么引入红黑树之后就解决了问题，那是怎么解决的呢，我说下自己的理解。
过程分析
既然数组扩容导致了变慢，那就是从扩容方向思考，谁决定了扩容呢？负载因子和数组长度。数组长度是resize自动做的，所以对用户来讲这应该是一个关注不到的变量，那就只剩负载因子了。负载因子越大，扩容的频率就越低。
1. 负载因子较小（小于1）
hash碰撞几率小，当数组元素链表长度达到8个的时候才会转成红黑树，满足这种条件的应该很极端很极端了，与JDK1.7之前的差异其实不大，存在扩容时卡顿。2. 负载因子较大（大于1）
hash碰撞几率大，所以一个数组元素出现红黑树的几率变大，每个树的数量也会很多。因为扩容的阈值调的比较大，导致轻易不会扩容，整个hashmap更偏向与一颗颗红黑树。扩容就可以理解为对红黑树的维护，达到了丝般顺滑的效果。
总结
根据前面的分析，引入红黑树主要好处有2个：
- 极端情况下，保证hashmap碰撞过多的元素的高性能操作。
- 负载因子变大情况，使hashmap倾向于一个红黑树的数组，带来的好处就是对元素的操作时间复杂度的整体稳定。
本质上还是得具体场景的权衡，如果数组太大，扩容会导致外部调用超时那就选择调大负载因子，达到削峰的目的。否则维持以前的用法就可以了，
完。