jdk1.8 HashMap底层数据结构图
Hashtable 初始容量是11 ，扩容方式为2N+1;HashMap 初始容量是16,扩容方式为2N;
扩容因子是0.75的原因是？ 提高空间利用率和 减少查询成本的折中，主要是泊松分布，0.75的话碰撞最小，
HashMap有两个参数影响其性能：初始容量和加载因子。容量是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。加载因子是哈希表在其容量自动扩容之前可以达到多满的一种度量。
当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表进行扩容resize()、rehash操作（即重建内部数据结构），扩容后的哈希表将具有两倍的原容量。
通常，加载因子需要在时间和空间成本上寻求一种折衷。
加载因子过高，例如为1，虽然减少了空间开销，提高了空间利用率，但同时也增加了查询时间成本；
加载因子过低，例如0.5，虽然可以减少查询时间成本，但是空间利用率很低，同时提高了rehash操作的次数。
在设置初始容量时应该考虑到映射中所需的条目数及其加载因子，以便最大限度地减少rehash操作次数，所以，一般在使用HashMap时建议根据预估值设置初始容量，减少扩容操作。
选择0.75作为默认的加载因子，完全是时间和空间成本上寻求的一种折衷选择，
HashMap源码中的加载因子
static final float DEFAULT_LOAD_FACTOR = 0.75f;
这是应该是“哈希冲突”和“空间利用率”矛盾的一个折衷。
跟数据结构要么查询快要么插入快一个道理，hashmap就是一个插入慢、查询快的数据结构。
Java中HashMap的数据结构
HashMap实际上是一个“链表散列”的数据结构，即数组和链表的结合体。
看图就可以知道Java中的hashMap使用了拉链法处理冲突。
HashMap有一个初始容量大小，默认是16
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
为了减少冲突的概率，当hashMap的数组长度到了一个临界值就会触发扩容，把所有元素rehash再放到扩容后的容器中，这是一个非常耗时的操作。
而这个临界值由【加载因子】和当前容器的容量大小来确定：DEFAULT_INITIAL_CAPACITY*DEFAULT_LOAD_FACTOR ，即默认情况下是16x0.75=12时，就会触发扩容操作。
所以使用hash容器时尽量预估自己的数据量来设置初始值。
HashMap底层为什么是数组链表呢？这样的话，链表一长，在链表中查询的效率不是很低吗？
在JDK1.7以及1.7版本之前，HashMap对数组元素即链表的查询确实是从头节点开始查询的，这样链表一旦长了，效率比较低也是意料之中。
而在1.8中对HashMap的数据结构进行了一定的优化，其中增加了一个阈值对数组元素进行判断是否有必要进行红黑树变形（红黑树是一种二叉查找树），一旦链表长度达到了阈值，其数据结构便会变形为红黑树，提高了查询效率，但插入的效率并没有链表头插法那么高，这也可能是HashMap底层为什么不用红黑树组成的数组的原因之一。
性能对比：
- 链表：插入复杂度O(1)，查找复杂度O(n)
- 红黑树：插入复杂度O(logn)，查找复杂度O(logn)
- HashMap数组元素为链表的时候，插入直接使用头插，插入复杂度O(1)；当链表较短时候，查找数据时对性能并没有什么影响，如果链表一长，查找起来就很影响性能了。
- 在Java8中，如果链表长度到达了8个，就会转化为红黑树，提高了查找的性能，但每次插入新的数据，都得维护红黑树的结构，复杂度为O(logn)。这样算是对查找和插入元素时性能的一个权衡，毕竟存起来就是用来查的
在理想情况下,使用随机哈希码,节点出现的频率在hash桶中遵循泊松分布，同时给出了桶中元素个数和概率的对照表。
使用hash容器请尽量指定初始容量，且是2的幂次方。
加载因子是表示Hash表中元素的填满的程度。
加载因子越大,填满的元素越多,空间利用率越高，但冲突的机会加大了。
反之,加载因子越小,填满的元素越少,冲突的机会减小,但空间浪费多了。
冲突的机会越大,则查找的成本越高。反之,查找的成本越小。
因此,必须在 "冲突的机会"与"空间利用率"之间寻找一种平衡与折衷。
哈希冲突主要与两个因素有关，（1）填装因子，填装因子是指哈希表中已存入的数据元素个数与哈希地址空间的大小的比值，a=n/m ; a越小，冲突的可能性就越小，相反则冲突可能性较大；但是a越小空间利用率也就越小，a越大，空间利用率越高，为了兼顾哈希冲突和存储空间利用率，通常将a控制在0.6-0.9之间，而.net中的HashTable则直接将a的最大值定义为0.72 （虽然微软官方MSDN中声明HashTable默认填装因子为1.0，但实际上都是0.72的倍数），（2）与所用的哈希函数有关，如果哈希函数得当，就可以使哈希地址尽可能的均匀分布在哈希地址空间上，从而减少冲突的产生。
但一个良好的哈希函数的得来很大程度上取决于大量的实践，不过幸好前人已经总结实践了很多高效的哈希函数。
可以参考大神Lucifer文章：数据结构：HashTable： http://www.cnblogs.com/lucifer1982/archive/2008/06/18/1224319.html
处理冲突的几种方法：
一、 开放定址法
Hi=(H(key) + di) MOD m i=1,2,...k(k<=m-1)其中H(key)为哈希函数；m为哈希表表长；di为增量序列。
开放定址法根据步长不同可以分为３种：
1）线性探查法(Linear Probing)：di=1,2,3,...,m-1
简单地说就是以当前冲突位置为起点，步长为１循环查找，直到找到一个空的位置就把元素插进去，循环完了都找不到说明容器满了。就像你去一条街上的店里吃饭，问了第一家被告知满座，然后挨着一家家去问是否有位置一样。
2）平方探测法或者二次探测法。
3）伪随机探测再散列：di=伪随机数序列。
缺点：
- 这种方法建立起来的hash表当冲突多的时候数据容易堆聚在一起，这时候对查找不友好；
- 删除结点不能简单地将被删结 点的空间置为空，否则将截断在它之后填人散列表的同义词结点的查找路径。因此在 用开放地址法处理冲突的散列表上执行删除操作，只能在被删结点上做删除标记，而不能真正删除结点
- 当空间满了，还要建立一个溢出表来存多出来的元素。
二、再哈希法/再散列法
Hi = RHi（key），i=1,2,...k
RHi均是不同的哈希函数，即在同义词产生地址冲突时计算另一个哈希函数地址，直到不发生冲突为止。这种方法不易产生聚集，但是增加了计算时间。
缺点：增加了计算时间。
三、建立一个公共溢出区
假设哈希函数的值域为[0,m-1]，则设向量HashTable[0...m-1]为基本表，每个分量存放一个记录，另设立向量OverTable[0....v]为溢出表。所有关键字和基本表中关键字为同义词的记录，不管他们由哈希函数得到的哈希地址是什么，一旦发生冲突，都填入溢出表。
简单地说就是搞个新表存冲突的元素。
四、链地址法（拉链法）
将所有关键字为同义词的记录存储在同一线性链表中，也就是把冲突位置的元素构造成链表。
拉链法的优点:
- 拉链法处理冲突简单，且无堆积现象，即非同义词决不会发生冲突，因此平均查找长度较短；
- 由于拉链法中各链表上的结点空间是动态申请的，故它更适合于造表前无法确定表长的情况；
- 在用拉链法构造的散列表中，删除结点的操作易于实现。只要简单地删去链表上相应的结点即可。
拉链法的缺点：
- 指针需要额外的空间，故当结点规模较小时，开放定址法较为节省空间，而若将节省的指针空间用来扩大散列表的规模，可使装填因子变小，这又减少了开放定址法中的冲突，从而提高平均查找速度