在元素的装载数量明确的时候HashMap的大小应该如何选择?

美团招聘给出了一道小题目，关于HashMap的性能问题。
Hash如果确定只装载100个元素，new HashMap(?)多少是最佳的，why？

影响HashMap的实例有两个参数会影响性能：初始容量和加载因子。
容量是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。
加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中条目的数目超过 容量乘加载因子 的时候，则要对该哈希表进行rehash操作，从而哈希表将具有大约两倍的桶数。
HashMap默认的加载因子是0.75 .它在时间和空间成本上寻求了一种折中。
HashMap默认的加载因子是0.75 .它在时间和空间成本上寻求了一种折中。

回到本文的问题。根据JDK中的描述，如果这个只装载100个元素的HashMap没有特殊的用途，那么为了在时间和空间上达到最佳性能，HashMap的初始容量可以设为

100/0.75 = 133.33。为了防止rehash，向上取整，为134。

但是还有另外一个问题，就是hash碰撞的问题。如果我们将HashMap的容量设置为134，那么如何保证其中的哈希碰撞会比较少呢？

除非重写hashcode()方法，否则，似乎没有办法保证。

那么这里不得不提HashMap如何为元素选择下标的方法了。

    static int indexFor(