在JDK 1.8中，最为经典的改动就是对HashMap的改动，当链表中元素数量超过一定阈值时，默认情况下是8的时候，将链表结构转换为红黑树，这一改动的原因主要是为了提高性能，尤其是在处理大量哈希冲突时，能更好地保证较优的时间复杂度。下面我们就来详细介绍一下HashMap为什么要进行这样的改动。

优化最坏情况下的查找性能

在JDK 1.8 之前HashMap的存储是采用了数组 + 链表的方式来存储数据。当多个键的哈希值相同的时候，就有可能会产生大量的哈希冲突，它们会被存储在同一个桶中，形成一个链表。

在理想的情况下，哈希冲突少，链表的长度较短，查找性能接近 O(1)。但是在最坏情况下，如果发生大量哈希冲突，链表长度变长，查找的时间复杂度将退化到 O(n)，这对性能是非常不利的。

所以在JDK1.8之后，引入了红黑树，红黑树是一种自平衡二叉搜索树，它能保证在最坏情况下仍然有较好的性能表现。当链表长度超过阈值时，链表会自动转换成红黑树，这样可以将最坏情况下的查找、插入和删除操作的时间复杂度从 O(n) 降低到 O(log n)。

提升哈希冲突严重时的性能

在某些极端情况下，当我们用到的哈希函数设计不巧妙的时候，或者是有人故意构造具有相同哈希值的键，这个时候HashMap的存储性能将会急剧下降，而引入红黑树之后，则可以大大缓解这种情况。

即使发生大量哈希冲突，性能也不会退化到线性级别。对于大数据量的应用场景，这种优化能明显提高 HashMap 的稳定性和性能。

平衡了空间和时间的消耗

使用红黑树相比链表会有额外的空间开销，例如要存储红黑树的父节点信息、颜色信息等，但是这个空间开销相对来说是可控的，因为只有当链表的长度超过 8 时才会转换为红黑树，在小于8的时候，还是用链表存储。

而且，对于大多数使用场景，哈希冲突是较少的，链表结构依然能很好地工作，因此并不会导致整体内存消耗的大幅增加。

简化维护和优化代码

红黑树的引入，同时也简化了对于HashMap的在处理哈希冲突时的代码优化工作，开发人员不需要手动的对HashMap中的键值冲突进行处理，因为JDK自身的实现能够自动适应不同的冲突情况，保证了高效和稳定的性能表现。

总结

JDK 1.8 对 HashMap 引入红黑树的改动，主要目的是提升在哈希冲突严重时的性能，特别是避免最坏情况下时间复杂度退化到 O(n)。这种改动平衡了时间复杂度和空间消耗，使 HashMap 在处理大量数据和复杂哈希冲突时仍能保持较优的性能。