阿里《JAVA开发手册》为什么建议设置HashMap的初始容量，设置多少合适

男娘i 2022-09-07 10:00 203阅读 0赞

**目录**

要设置HashMap的初始化容量

HashMap初始化容量设置多少合适

--------------------

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70][]

集合是Java开发日常开发中经常会使用到的，而作为一种典型的K-V结构的数据结构，HashMap对于Java开发者一定不陌生。

关于HashMap，很多人都对他有一些基本的了解，比如他和hashtable之间的区别、他和concurrentHashMap之间的区别等。这些都是比较常见的，关于HashMap的一些知识点和面试题，想来大家一定了熟于心了，并且在开发中也能有效的应用上。

但是，作者在很多次 CodeReview 以及面试中发现，有一个比较关键的小细节经常被忽视，那就是HashMap创建的时候，要不要指定容量？如果要指定的话，多少是合适的？为什么？

### [要设置HashMap的初始化容量][HashMap] ###

> HashMap中size表示当前共有多少个KV对，capacity表示当前HashMap的容量是多少，默认值是16，**每次扩容都是成倍的**。loadFactor是装载因子，当Map中元素个数超过`loadFactor* capacity`的值时，会触发扩容。`loadFactor* capacity`可以用threshold表示。
> 
> 在HashMap中，threshold = loadFactor \* capacity。
> 
> loadFactor是装载因子，表示HashMap满的程度，默认值为0.75f，设置成0.75有一个好处，那就是0.75正好是3/4，而capacity又是2的幂。所以，两个数的乘积都是整数。
> 
> 更多可以参考:　[为什么HashMap的加载因子是0.75？][HashMap_0.75]

所以，如果我们没有设置初始容量大小，随着元素的不断增加，HashMap会发生多次扩容，而HashMap中的扩容机制决定了每次扩容都需要重建hash表，是非常影响性能的。

所以，首先可以明确的是，**我们建议开发者在创建HashMap的时候指定初始化容量。**并且《阿里巴巴开发手册》中也是这么建议的：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70 1][]

>  默认情况下HashMap的容量是16，但是，如果用户通过构造函数指定了一个数字作为容量，那么Hash会选择大于该数字的第一个2的幂作为容量。(1->1、7->8、9->16)

### [HashMap初始化容量设置多少合适][HashMap 1] ###

那么，既然建议我们集合初始化的时候，要指定初始值大小，那么我们创建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版本）也被采用。

public void putAll(Map<? extends K, ? extends V> m) {
            tryPresize(m.size());
            for (Map.Entry<? extends K, ? extends V> e : m.entrySet())
                putVal(e.getKey(), e.getValue(), false);
        }
    
    
      final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
            int s = m.size();
            if (s > 0) {
                if (table == null) { // pre-size
                    float ft = ((float)s / loadFactor) + 1.0F;
                    int t = ((ft < (float)MAXIMUM_CAPACITY) ?
                             (int)ft : MAXIMUM_CAPACITY);
                    if (t > threshold)
                        threshold = tableSizeFor(t);
                }
                else if (s > threshold)
                    resize();
                for (Map.Entry<? extends K, ? extends V> e : m.entrySet()) {
                    K key = e.getKey();
                    V value = e.getValue();
                    putVal(hash(key), key, value, false, evict);
                }
            }
        }

这个值的计算方法就是：

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);

其代码实现如下：

public static <K, V> HashMap<K, V> newHashMap(Map<? extends K, ? extends V> map) {
        return new HashMap<>(map);
      }
    
      /**
       * Creates a {@code HashMap} instance, with a high enough "initial capacity" that it <i>should</i>
       * hold {@code expectedSize} elements without growth. This behavior cannot be broadly guaranteed,
       * but it is observed to be true for OpenJDK 1.7. It also can't be guaranteed that the method
       * isn't inadvertently <i>oversizing</i> the returned map.
       *
       * @param expectedSize the number of entries you expect to add to the returned map
       * @return a new, empty {@code HashMap} with enough capacity to hold {@code expectedSize} entries
       *     without resizing
       * @throws IllegalArgumentException if {@code expectedSize} is negative
       */
      public static <K, V> HashMap<K, V> newHashMapWithExpectedSize(int expectedSize) {
        return new HashMap<>(capacity(expectedSize));
      }
    
      /**
       * Returns a capacity that is sufficient to keep the map from being resized as long as it grows no
       * larger than expectedSize and the load factor is ≥ its default (0.75).
       */
      static int capacity(int expectedSize) {
        if (expectedSize < 3) {
          checkNonnegative(expectedSize, "expectedSize");
          return expectedSize + 1;
        }
        if (expectedSize < Ints.MAX_POWER_OF_TWO) {
          // This is the calculation used in JDK8 to resize when a putAll
          // happens; it seems to be the most conservative calculation we
          // can make.  0.75 is the default load factor.
          return (int) ((float) expectedSize / 0.75F + 1.0F);
        }
        return Integer.MAX_VALUE; // any large value
      }

但是，**以上的操作是一种用内存换性能的做法，真正使用的时候，要考虑到内存的影响。**但是，大多数情况下，我们还是认为内存是一种比较富裕的资源。

但是话又说回来了，有些时候，我们到底要不要设置HashMap的初识值，这个值又设置成多少，真的有那么大影响吗？其实也不见得！

可是，大的性能优化，不就是一个一个的优化细节堆叠出来的吗？

再不济，以后你写代码的时候，使用**Maps.newHashMapWithExpectedSize(7);**的写法，也可以让同事和老板眼前一亮。

或者哪一天你碰到一个面试官问你一些细节的时候，你也能有个印象，或者某一天你也可以拿这个出去面试问其他人~！啊哈哈哈。

参考链接:

[https://blog.csdn.net/u014532901/article/details/78936283][https_blog.csdn.net_u014532901_article_details_78936283]

[https://github.com/jifuwei/blog/issues/19][https_github.com_jifuwei_blog_issues_19]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70]: /images/20220829/12864387662c4a2e9180abdacdb48ee3.png
[HashMap]: http://xn--hashmap-0p0lj6et51ak5etx1hnhyauq3au9gl9z/
[HashMap_0.75]: https://blog.csdn.net/fly910905/article/details/116501300
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70 1]: /images/20220829/360114a0c4ea4527afd679ffccfc3945.png
[HashMap 1]: http://xn--hashmap-0p0lj6ef9c63vw4bsxki9a2346a5fubsfp6th/
[https_blog.csdn.net_u014532901_article_details_78936283]: https://blog.csdn.net/u014532901/article/details/78936283
[https_github.com_jifuwei_blog_issues_19]: https://github.com/jifuwei/blog/issues/19