HashMap真的是大于8就转换成红黑树，小于6就变成链表吗？？？
HashMap的底层是数组+链表，（很多人应该都知道了）
JDK1.7的是数组+链表
（1.7只是一个例子，以前的话也是这样后面就以1.7为例子了）
首先是一个数组，然后数组的类型是链表
元素是头插法
JDK1.8的是数组+链表 或者 数组+红黑树
首先是一个数组，然后数组的类型是链表
在链表的元素大于8的时候，会变成红黑树
（当链表长度大于8并且数组长度大于64时，才会转换为红黑树。
如果链表长度大于8，但是数组长度小于64时，还是会进行扩容操作，不会转换为红黑树。因为数组的长度较小，应该尽量避开红黑树。因为红黑树需要进行左旋，右旋，变色操作来保持平衡，
所以当数组长度小于64，使用数组加链表比使用红黑树查询速度要更快、效率要更高。）
在红黑树的元素小于6的时候会变成链表
（这里需要注意，不是元素小于6的时候一定会变成链表，只有resize的时候才会根据UNTREEIFY_THRESHOLD 进行转换，同样也不是到8的时候就变成红黑树（不是等到扩容的时候） 链表与红黑树的转换详情）
元素进行尾插
数学计算
红黑树的平均查找长度是log(n)，长度为8，查找长度为log(8)=3，链表的平均查找长度为n/2，当长度为8时，平均查找长度为8/2=4，这才有转换成树的必要；链表长度如果是小于等于6，6/2=3，虽然速度也很快的，但是转化为树结构和生成树的时间并不会太短。
还有选择6和8的原因是：
中间有个差值7可以防止链表和树之间频繁的转换。假设一下，如果设计成链表个数超过8则链表转换成树结构，链表个数小于8则树结构转换成链表，如果一个HashMap不停的插入、删除元素，链表个数在8左右徘徊，就会频繁的发生树转链表、链表转树，效率会很低。
HaspMap的数组默认大小为16
数组也叫做Hash桶
（貌似听说这个值和阿里巴巴Java开发手册好像有点关系）
HashMap元素的下标是
//这是Hash值
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
//这是下标得计算
Hash值(元素) & (数组的长度-1)
（ 只要数组大小是2的幂，则 (n-1) & hash 的结果等效于： hash % (n-1)；即与运算、求余运算通过这个前提，实现了等效。——感谢来自评论区大佬的指点）
HashMap的扩容 Resize
扩容的话，这里有一个值叫做loadFactor（阈值），默认值为0.75;
当数组的 元素数量>数组大小（默认16）* loadFactor（默认0.75）
就会触发扩容，扩容是二倍扩容的 （默认是16扩容后就是32）
这时原来每个元素的下标也会改变的（因为数组的长度变了）
然后就要把每个元素重新分配下标，重新加入链表或者红黑树
HashMap线程不安全
在put的时候，Resize（扩容）会造成数据的覆盖
JDK1.7 因为是头插法，可能会造成循环链表
JDK1.8 是尾插法
使用HashMap怎么才能让他线程安全
使用ConcurrentHashMap，
JDK1.7的是分段数组，有Segment锁（继承于ReentrantLock）加速一小段保证并发
JDK1.8 是和HashMap一样了，数组+链表（或者红黑树）
Synchronized（锁）and CAS（compare and swap）
（JVM在1.6对Synchronize的优化很好）
CAS通俗易懂，比较并替换
（CAS是一种无锁算法，CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做）
（无锁化的修改值的操作，他可以大大降低锁代理的性能消耗。这个算法的基本思想就是不断地去比较当前内存中的变量值与你指定的 一个变量值是否相等，如果相等，则接受你指定的修改的值，否则拒绝你的操作。因为当前线程中的值已经不是最新的值，你的修改很可能会覆盖掉其他线程修改的结果。这一点与乐观锁，SVN的思想是比较类似的）
使用HashTable（基本是废弃的）
HashTable就是把HashMap套上了一个Synchronized
Collections.synchronizedMap()包装
使用synchronized 加上，但是这个是对某个Hash桶（数组的某个值）加锁，并不是整个map加锁，在锁定的时候别的线程也可以进行访问