为什么阿里巴巴建议HashMap初始化时需要指定容量大小？

为什么阿里巴巴建议HashMap初始化时需要指定容量大小？

为什么？

关于集合类，《阿里巴巴Java开发手册》中写道：

 

我们先来写一段代码在JDK 1.7 （jdk1.7.0_80）下面来分别测试下，在不指定初始化容量和指定初始化容量的情况下性能情况如何。（jdk 8 结果会有所不同，我会在后面的文章中分析）

public static void main(String[] args) {
    int aHundredMillion = 10000000;
​
    Map<Integer, Integer> map = new HashMap<>();
​
    long s1 = System.currentTimeMillis();
    for (int i = 0; i < aHundredMillion; i++) {
        map.put(i, i);
    }
    long s2 = System.currentTimeMillis();
​
    System.out.println("未初始化容量，耗时 ： " + (s2 - s1));
​
​
    Map<Integer, Integer> map1 = new HashMap<>(aHundredMillion / 2);
​
    long s5 = System.currentTimeMillis();
    for (int i = 0; i < aHundredMillion; i++) {
        map1.put(i, i);
    }
    long s6 = System.currentTimeMillis();
​
    System.out.println("初始化容量5000000，耗时 ： " + (s6 - s5));
​
​
    Map<Integer, Integer> map2 = new HashMap<>(aHundredMillion);
​
    long s3 = System.currentTimeMillis();
    for (int i = 0; i < aHundredMillion; i++) {
        map2.put(i, i);
    }
    long s4 = System.currentTimeMillis();
​
    System.out.println("初始化容量为10000000，耗时 ： " + (s4 - s3));
}

 

以上代码不难理解，我们创建了3个HashMap，分别使用默认的容量（16）、使用元素个数的一半（5千万）作为初始容量、使用元素个数（一亿）作为初始容量进行初始化。然后分别向其中put一亿个KV。

从结果中，我们可以知道，在已知HashMap中将要存放的KV个数的时候，设置一个合理的初始化容量可以有效的提高性能。

这是因为HashMap有扩容机制，就是当达到扩容条件时会进行扩容。HashMap的扩容条件就是当HashMap中的元素个数（size）超过临界值（threshold）时就会自动扩容。在HashMap中，threshold = loadFactor * capacity。

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

从上面的代码示例中，我们还发现，同样是设置初始化容量，设置的数值不同也会影响性能，那么当我们已知HashMap中即将存放的KV个数的时候，容量设置成多少为好呢？

HashMap中容量的初始化

默认情况下，当我们设置HashMap的初始化容量时，实际上HashMap会采用第一个大于该数值的2的幂作为初始化容量。

当我们通过HashMap(int initialCapacity)设置初始容量的时候，HashMap并不一定会直接采用我们传入的数值，而是经过计算，得到一个新值，目的是提高hash的效率。(1->1、3->4、7->8、9->16)

不管是Jdk 1.7还是Jdk 1.8，计算初始化容量的算法其实是如出一辙的，主要代码如下：

    int n = cap - 1;
    n |= n >>> 1;
    n |= n >>> 2;
    n |= n >>> 4;
    n |= n >>> 8;
    n |= n >>> 16;
    return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;

JDK1.7中是highestOneBit()方法，1.8中是tableSizeFor()方法。

 

 

作用都是返回一个比入参刚好大的2的次方的一个数。复制测试以下

public class TestTableSizeFor {
​
    public static void main(String[] args) {
        System.out.println(tableSizeFor(1));
        System.out.println(tableSizeFor(2));
        System.out.println(tableSizeFor(3));
        System.out.println(tableSizeFor(10));
        System.out.println(tableSizeFor(27));
    }
​
    static final int tableSizeFor(int cap) {
        int n = cap - 1;
        n |= n >>> 1;
        n |= n >>> 2;
        n |= n >>> 4;
        n |= n >>> 8;
        n |= n >>> 16;
        return  n + 1;
    }
}

 

HashMap初始容量时机

在Jdk 1.7和Jdk 1.8中，HashMap初始化这个容量的时机不同。jdk1.8中，在调用HashMap的构造函数定义HashMap的时候，就会进行容量的设定。而在Jdk 1.7中，要等到第一次put操作时才进行这一操作。

我们可以通过反射来验证一下。

public static void main(String[] args) {
        int aHundredMillion = 10000000;
​
        Map<Integer, Integer> map = new HashMap<>();
​
        long s1 = System.currentTimeMillis();
        for (int i = 0; i < aHundredMillion; i++) {
            map.put(i, i);
        }
        long s2 = System.currentTimeMillis();
​
        System.out.println("未初始化容量，耗时 ： " + (s2 - s1));
​
​
        Map<Integer, Integer> map1 = new HashMap<>(aHundredMillion / 2);
​
        long s5 = System.currentTimeMillis();
        for (int i = 0; i < aHundredMillion; i++) {
            map1.put(i, i);
        }
        long s6 = System.currentTimeMillis();
​
        System.out.println("初始化容量5000000，耗时 ： " + (s6 - s5));
​
​
        Map<Integer, Integer> map2 = new HashMap<>(aHundredMillion);
​
        long s3 = System.currentTimeMillis();
        for (int i = 0; i < aHundredMillion; i++) {
            map2.put(i, i);
        }
        long s4 = System.currentTimeMillis();
​
        System.out.println("初始化容量为10000000，耗时 ： " + (s4 - s3));
    }

因为HashMap没有容量这个属性，但是capacity方法会返回容量

JDK1.7

 

在jdk1.7初始化容量的时机是在第一次put的时候，我们可以查看一下capacity()源码

 

 

1.7中capacity()方法返回的是table.length即HashMap的容量，而构造方法并没有对改属性进行赋值操作。反而是在第一次put的时候才进行了操作。

 

 put()---->inflateTable()---->table中才进行操作

JDK1.8

jdk1.8中，在调用HashMap的构造函数定义HashMap的时候，就会进行容量的设定。

赋值了threshold属性

查看capacity()方法，HashMap容量返回的是threshold属性

 

HashMap中初始容量的合理值

当我们使用HashMap(int initialCapacity)来初始化容量的时候，jdk会默认帮我们计算一个相对合理的值当做初始容量。那么，是不是我们只需要把已知的HashMap中即将存放的元素个数直接传给initialCapacity就可以了呢？

关于这个值的设置，在《阿里巴巴Java开发手册》有以下建议：

initialCapacity = (需要存储的元素个数 / 负载因子) + 1。注意负载因子（即 loader factor）默认 为 0.75，如果暂时无法确定初始值大小，请设置为 16（即默认值）。

也就是说，如果我们设置的默认值是7，经过Jdk处理之后，会被设置成8，但是，这个HashMap在元素个数达到 8*0.75 = 6的时候就会进行一次扩容，这明显是我们不希望见到的。

如果我们通过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是一个在性能上相对好的选择，但是，同时也会牺牲些内存。

总结

当我们想要在代码中创建一个HashMap的时候，如果我们已知这个Map中即将存放的元素个数，给HashMap设置初始容量可以在一定程度上提升效率。在已知HashMap中将要存放的KV个数的时候，设置一个合理的初始化容量按照 expectedSize / 0.75F + 1.0F 可以有效的提高性能，减少扩容次数。

但是，JDK并不会直接拿用户传进来的数字当做默认容量，而是会进行一番运算，最终得到一个2的幂。得到这个数字的算法其实是使用了使用无符号右移和按位或运算来提升效率。