HashMap初始化容量
《阿里巴巴Java开发规约》中有提到：
【推荐】集合初始化时，指定集合初始值大小。
说明：HashMap使用如下构造方法进行初始化，如果暂时无法确定集合大小，那么指定默认值（16）即可：
public HashMap (int initialCapacity) {
this(initialCapacity, DEFAULT_LOAD_FACTOR);
}那么HashMap的初始化值到底应该是多少呢？想要得出这个问题答案，必须先了解一下HashMap的部分特征
HashMap的实例有两个参数影响其性能：初始容量和加载因子
容量是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。HashMap的默认大小为16
加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度。HashMap默认的加载因子是0.75 .它在时间和空间成本上寻求了一种折中。
当哈希表中条目的数目超过 容量 * 加载因子 的时候，则要对该哈希表进行rehash操作，从而哈希表将具有大约两倍的桶数。
再回到正题，如果确定只装载100个元素，new HashMap()初始化容量多少是最佳的？
根据上文的推测，如果这个只装载100个元素的HashMap没有特殊的用途，那么为了在时间和空间上达到最佳性能，HashMap的初始容量可以设为 100/0.75 = 133.33。为了防止rehash，向上取整，为134。
但是还有另外一个问题，就是hash碰撞的问题。如果我们将HashMap的容量设置为134，那么如何保证其中的哈希碰撞会比较少呢？
除非重写hashcode()方法，否则，似乎没有办法保证。
HashMap在这也有一个解决方案就是选择下标方法：
static int indexFor(int h, int length) {
return h & (length-1);
}其中h为key哈希后得到的值，length为哈希表的长度。
那么 length-1的二进制值的最后3位为101；
假设这100个装载的元素中他们的key在哈希后有得到两个值（h），他们的二进制值除了低3位之外都相同，而第一个值的低3位为011，第二个值的低3位为001；
这时候进行java的&预算，011 & 101 = 001 ；001 & 101 = 001；
他们的值相等了，那么这个时候就会发生哈希碰撞。
除此之外还有一个更加严重的问题，由于在101中第二位是0，那么，无论我们的key在哈希运算之后得到的值h是什么，那么在&运算之后，得到的结果的倒数第二位均为0；
因此，对于hash表所有下标的二进制的值而言，只要低位第二位的值为1，（例如0010,0011,0111,1111）那么这个下标所代表的桶将一直是空的，因为代码中的&运算的结果永远不会产生低位第二位为1的值。这就大大地浪费了空间，同时还增加了哈希碰撞的概率。这无疑会降低HashMap的效率。
那么如何才能减少这种浪费呢？最佳的方法当然是让length-1的二进制值全部位均为1.那么length的值是多少合适呢？
没错，length=2^n。
只要将hash表的长度设为2的N次方，那么，所有的哈希桶均有被使用的可能。
所以上面的答案应该为256
后话：
JDK并不会直接拿用户传进来的数字当做默认容量，而是会进行一番运算，最终得到一个2的幂
也就是说，无论你的HashMap(x)中的x设置为多少，HashMap的大小都是2n。2n是大于x的第一个数。
因此关于这个值的设置，在《阿里巴巴Java开发手册》有以下建议：
正例：initialCapacity = (需要存储的元素个数 / 负载因子) + 1。注意 负载因子（即loader factor）默认 为 0.75，如果 暂时 无法确定 初始 值大小，请设置 为 16。