京东二面：为什么HashMap底层树化标准的元素个数是8？

一般的面试题

对于HashMap，我们再熟悉不过了，日常开发最常用的Java集合类就是它了，而且面试的时候对于HashMap知识点基本是必问的，就拿我之前的面试经历来看，问的最多的无非是这么几个：

1. HashMap的底层存储结构是怎样的啊？
2. 线程安全吗？为什么不安全？
3. 1.7和1.8版本的HashMap有什么区别？1.7的有什么隐患，什么原因导致的？
4. hashcode是唯一的吗？插入元素的时候怎么比较的？
5. 跟HashTable，ConcurrentHashMap有什么区别？

对于这些问题，如果你看过一些博客，或者大概的浏览过源码的话，基本都能答出来，我之前参加过很多面试，也很少在HashMap这块失过手。

事实证明，我还是年轻了点。有时候，你答的好不是因为你懂得多，而是人家问的不深，如果你没有对源码做深入的了解和思考的话，别人稍微换个角度考察，你也许就会犯难了。

就好像标题上的题目，为什么HashMap链表树化的标准是8个？说实话，尽管我之前也知道是树化的阈值是8，但是为什么是这个数目我还真没仔细的思考过，借着这个机会，我也重新梳理了遍HashMap的源码，本文也算是一些新的思考点的总结吧。

HashMap的基本知识点

HashMap可以说是Java项目里最常用的集合类了，作为一种典型的K-V存储的数据结构，它的底层是由数组 - 链表组成，当添加新元素时，它会根据元素的hash值找到对应的"桶"，也就是HashMap源码中Node 里的元素，并插入到对应位置的链表中，链表元素个数过长时会转化为红黑树(JDK1.8后的版本)，

为什么要转成红黑树呢？

我们都知道，链表取元素是从头结点一直遍历到对应的结点，这个过程的复杂度是O(N) ，而红黑树基于二叉树的结构，查找元素的复杂度为O(logN) ，所以，当元素个数过多时，用红黑树存储可以提高搜索的效率。

既然红黑树的效率高，那怎么不一开始就用红黑树存储