hashMap的初始容量为16

Java规范 HashMap初始容量与容量大小
这是两个问题

为什么设置初始容量
初始容量多大合适

第一个问题：为什么设置初始容量

这个答案其实通过阅读源码也可以得到。简单来说就是避免扩容带来的效率问题。扩容机制具体详见源码。

在初始化 HashMap 的时候，应该尽量指定其大小。尤其是当你已知 map 中存放的元素个数时。（《阿里巴巴 Java 开发规约》）
第二个问题：初始容量多大合适

那么，既然建议我们集合初始化的时候，要指定初始值大小，那么我们创建

HashMap 的时候，到底指定多少合适呢？
有些人会自然想到，我准备塞多少个元素我就设置成多少呗。比如我准备塞 7 个元素，那就 new HashMap(7)。但是，这么做不仅不对，而且以上方式创建出来的 Map 的容量也不是 7。因 为， 当 我 们 使 用 HashMap(int initialCapacity) 来 初 始 化 容 量 的 时 候，HashMap 并不会使用我们传进来的 initialCapacity 直接作为初识容量。JDK 会默认帮我们计算一个相对合理的值当做初始容量。所谓合理值，其实是找到第一个比用户传入的值大的 2 的幂。也就是说，当我们 new HashMap(7) 创建 HashMap 的时候，JDK 会通过计算，帮我们创建一个容量为 8 的 Map；当我们 new HashMap(9) 创建 HashMap 的时候，JDK 会通过计算，帮我们创建一个容量为 16 的 Map。但是，这个值看似合理，实际上并不尽然。因为 HashMap 在根据用户传入的capacity 计算得到的默认容量，并没有考虑到 loadFactor 这个因素，只是简单机械的计算出第一个大约这个数字的 2 的幂。
loadFactor 是负载因子，当 HashMap 中的元素个数（size）超过 threshold

= loadFactor * capacity 时，就会进行扩容。也就是说，如果我们设置的默认值是 7，经过 JDK 处理之后，HashMap 的容量会被设置成 8，但是，这个 HashMap 在元素个数达到 8*0.75 = 6 的时候就会进行一次扩容，这明显是我们不希望见到的。
那么，到底设置成什么值比较合理呢？

这里我们可以参考 JDK8 中 putAll 方法中的实现的，这个实现在 guava（21.0版本）也被采用。这个值的计算方法就是：
return (int) ((float) expectedSize / 0.75F + 1.0F);
比如我们计划向 HashMap 中放入 7 个元素的时候，我们通过 expectedSize /0.75F + 1.0F 计算，7/0.75 + 1 = 10 ,10 经过 JDK 处理之后，会被设置成 16，这就大大的减少了扩容的几率。

当 HashMap 内 部 维 护 的 哈 希 表 的 容 量 达 到 75% 时（默 认 情 况 下）， 会 触发 rehash， 而 rehash 的 过 程 是 比 较 耗 费 时 间 的。 所 以 初 始 化 容 量 要 设 置 成expectedSize/0.75 + 1 的话，可以有效的减少冲突也可以减小误差。所以，我们可以认为，当我们明确知道 HashMap 中元素的个数的时候，把默认容量设置成 expectedSize / 0.75F + 1.0F 是一个在性能上相对好的选择，但是，同时也会牺牲些内存。
这个算法在 guava 中有实现，开发的时候，可以直接通过 Maps 类创建一个HashMap：

Map<String, String> map = Maps.newHashMapWithExpectedSize(7);
其代码实现如下：36　　>　Java 开发手册建议创建 HashMap 时设置初始化容量，但是多少合适呢？

public static <K, V> HashMap<K, V> newHashMapWithExpectedSize(int expectedSize) {

return new HashMap(capacity(expectedSize));

}

static int capacity(int expectedSize) {

if (expectedSize < 3) {

CollectPreconditions.checkNonnegative(expectedSize, “expectedSize”);

return expectedSize + 1;

} else {

return expectedSize < 1073741824 ? (int)((float)expectedSize/0.75F+1.0F) : 2147483647;

}

}
但是， 以上的操作是一种用内存换性能的做法，真正使用的时候，要考虑到内存的影响。但是，大多数情况下，我们还是认为内存是一种比较富裕的资源。但是话又说回来了，有些时候，我们到底要不要设置 HashMap 的初识值，这个值又设置成多少，真的有那么大影响吗？其实也不见得！可是，大的性能优化，不就是一个一个的优化细节堆叠出来的吗？再 不 济， 以 后 你 写 代 码 的 时 候， 使 用 Maps.newHashMapWithExpectedSize(7); 的写法，也可以让同事和老板眼前一亮。或者哪一天你碰到一个面试官问你一些细节的时候，你也能有个印象，或者某一天你也可以拿这个出去面试问其他人 ~ ！啊哈哈哈

JDK构造方法摘要




HashMap()
构造一个具有默认初始容量 (16) 和默认加载因子 (0.75) 的空 HashMap。




HashMap(int initialCapacity)
造一个带指定初始容量和默认加载因子 (0.75) 的空 HashMap。


HashMap(int initialCapacity, float loadFactor)
构造一个带指定初始容量和加载因子的空 HashMap。


HashMap(Map<? extends K,? extends V> m)
构造一个映射关系与指定 Map 相同的新 HashMap。


一、概念
    HashMap 的实例有两个参数影响其性能：初始容量和加载因子。容量是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表进行 rehash 操作（即重建内部数据结构），从而哈希表将具有大约两倍的桶数。
    通常，默认加载因子 (0.75) 在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销，但同时也增加了查询成本（在大多数 HashMap 类的操作中，包括 get 和put 操作，都反映了这一点）。在设置初始容量时应该考虑到映射中所需的条目数及其加载因子，以便最大限度地减少 rehash 操作次数。如果初始容量大于最大条目数除以加载因子，则不会发生 rehash 操作。
二、举例
像HashMap，默认大小是16，也就是支持存储最多20个键值对，如果不超过20个键值对，可以不设置，如果超出，按如下公式计算后设置：
initialCapacity = (需要存储的元素（键值对）个数 / 负载因子) + 1
但是，hashmap在我们存放的数据大于初始化容量*负载因子（默认0.75）时就会自动扩容，自动扩容是非常消耗性能的。因为元素要重新hash分配。

最近遇到一个关于hashmap的面试题，关于指定处理容量的。初始容量就是指定容器的初始大小，但是如果超过了初始容量会发生什么呢？是会数组越界异常，因为初始容量指定的是key的个数，而key是存在数组里面的。因为数组指定大小后就不可变，所以超过容量会报异常