正文

一些Java編程老手在做CodeReview時(shí)，都會(huì)告訴其他人，使用HashMap時(shí)建議指定容量大小，原因是指定容量后，代碼性能會(huì)更好一些。后來(lái)隨著阿里Java開發(fā)手冊(cè)在業(yè)內(nèi)廣為傳播，這一點(diǎn)早已深入人心，我自己也早已習(xí)慣在使用HashMap時(shí)指定容量大小。

但我今天突發(fā)奇想，想知道指定容量和不指定容量時(shí)性能究竟有多少的差異，測(cè)試部分測(cè)試數(shù)據(jù)的結(jié)果讓我大跌眼睛，有些情況下指定容量的性能還比不指定容量時(shí)差??！ ，但其他部分還是很符合我之前的認(rèn)知的。

openjdk17和jmh單線程測(cè)試

先說(shuō)下我的測(cè)試平臺(tái)和測(cè)試方法，我使用了openjdk17和jmh單線程測(cè)試，測(cè)試代碼如下：

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    @Measurement(iterations = 2, time = 5)
    @Threads(1)
    @Fork(0)
    @Warmup(iterations = 1, time = 5)
    public void withoutCap() {
        Map<Integer, Integer> map = new HashMap<>();
        for (int i = 0; i < CAP; i++) {
            map.put(random.nextInt(), 1);
        }
    }
    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    @Measurement(iterations = 2, time = 5)
    @Threads(1)
    @Fork(0)
    @Warmup(iterations = 1, time = 5)
    public void withCap() {
        Map<Integer, Integer> map = new HashMap<>(CAP);
        for (int i = 0; i < CAP; i++) {
            map.put(random.nextInt(), 1);
        }
    }

這里為了避免Java中小數(shù)據(jù)緩存，我特意使用了隨機(jī)數(shù)作為KEY，而VALUE一視同仁都使用了1。兩個(gè)方法就是新建一個(gè)HashMap并不斷往map里put數(shù)據(jù)，唯一差異就是一個(gè)指定了CAP參數(shù)。 在我設(shè)置了不同參數(shù)后，得到了以下數(shù)據(jù)（越高越好）：

可以看出，容量16是個(gè)分水嶺，當(dāng)容量為16時(shí)，二者幾乎沒(méi)啥差異，這也很容易理解，當(dāng)不指定容量時(shí)默認(rèn)初始容量就是16。

• 但容量大于16時(shí)，指定容量時(shí)的性能會(huì)高于不指定時(shí)的性能，隨著數(shù)量的增加，前者會(huì)比后者性能高出50%。
• 但當(dāng)數(shù)據(jù)量小于16時(shí)，不指定容量大小反而性能更高，最多甚至相差2倍，這就和我們之前的認(rèn)知不一樣了。

上面數(shù)據(jù)中還有個(gè)很奇怪的點(diǎn)，那就是當(dāng)數(shù)據(jù)量為1025時(shí)，性能居然還高于1024，而且差異巨大。就好比別人比你多干了1份活，但用的時(shí)間比你少一半。我跑了多次都是這個(gè)結(jié)果，這不是測(cè)試誤差，這個(gè)結(jié)果和計(jì)算機(jī)底層存儲(chǔ)實(shí)現(xiàn)有關(guān)，具體原理可以參考問(wèn)題 為什么轉(zhuǎn)置512x512的矩陣比轉(zhuǎn)置513x513的矩陣慢？

備注：以上數(shù)據(jù)經(jīng)過(guò)多次運(yùn)行測(cè)試，數(shù)據(jù)雖有波動(dòng)，但數(shù)據(jù)波動(dòng)基本都在3%以內(nèi)。

那為什么在大數(shù)據(jù)量的情況下，指定容量的代碼性能會(huì)更好呢？這就得說(shuō)到HashMap的實(shí)現(xiàn)原理，更詳細(xì)內(nèi)容可以參考我之前寫的HashMap源碼淺析。這里為了方便大家直觀地理解性能差異產(chǎn)生的原因，我們用牧場(chǎng)養(yǎng)羊類比下。

假設(shè)你要開始養(yǎng)羊，你得現(xiàn)有場(chǎng)地吧，假設(shè)你先找了塊小場(chǎng)地，但隨著你的羊群發(fā)展壯大，場(chǎng)地不夠用了，你就得搬到一個(gè)更大的新場(chǎng)地，如果發(fā)展速度特別快，你就得頻繁搬家，搬家就逐漸變成了負(fù)擔(dān)。但如果你一開始就知道你最多能養(yǎng)多少的羊，直接找個(gè)足夠大的場(chǎng)地，不就能省去一直搬家的成本了嗎！

這里你把羊類比成數(shù)據(jù)，場(chǎng)地類比為內(nèi)存，在HashMap中，如果開始不指定容量大小，JVM默認(rèn)會(huì)給你一個(gè)非常小的(16)的容量空間，如果之后數(shù)據(jù)量變多，就需要重新申請(qǐng)更大的空間，并把數(shù)據(jù)遷移到新空間上，于是額外增加了時(shí)間消耗。這便是性能差異產(chǎn)生的原因。

但當(dāng)容量小于16時(shí)，指定容量的方式反而性能更差。這個(gè)我之前從未看過(guò)其他資料有說(shuō)過(guò)，我簡(jiǎn)單談下自己的分析和理解。 當(dāng)調(diào)用new HashMap()和new HashMap(CAP)時(shí)，分別執(zhí)行了不同的構(gòu)造函數(shù)，而二者的構(gòu)造函數(shù)的邏輯是有差異的，當(dāng)指定容量時(shí)，執(zhí)行了容量參數(shù)檢查的代碼：

    public HashMap(int initialCapacity, float loadFactor) {
        if (initialCapacity < 0)
            throw new IllegalArgumentException("Illegal initial capacity: " +
                                               initialCapacity);
        if (initialCapacity > MAXIMUM_CAPACITY)
            initialCapacity = MAXIMUM_CAPACITY;
        if (loadFactor <= 0 || Float.isNaN(loadFactor))
            throw new IllegalArgumentException("Illegal load factor: " +
                                               loadFactor);
        this.loadFactor = loadFactor;
        this.threshold = tableSizeFor(initialCapacity);
    }
    static final int tableSizeFor(int cap) {
        int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1);
        return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
    }

不指定容量時(shí)，構(gòu)造方法內(nèi)只有一行this.loadFactor = DEFAULT_LOAD_FACTOR;，在put的數(shù)據(jù)量一致時(shí)，后續(xù)所有的代碼執(zhí)行流程都是一致的，所以指定容量時(shí)，上面容量參數(shù)檢查的代碼帶來(lái)了額外的性能負(fù)擔(dān)，所以導(dǎo)致數(shù)據(jù)量較小時(shí)指定容量時(shí)反而性能更差一些。

總結(jié)

最后回到文章標(biāo)題上來(lái)，Java中使用HashMap時(shí)指定初始化容量性能一定會(huì)更好嘛？答案是不一定，指定容量也有可能性能會(huì)更差。當(dāng)然，絕大多數(shù)情況下還是建議指定容量的，類似的還有ArrayList，也建議指定容量。 別人給出的結(jié)論不一定的完全正確的，只有知道產(chǎn)生結(jié)論的原因，才能更有效的利用這個(gè)結(jié)論。

以上就是Java中使用HashMap時(shí)指定初始化容量性能解析的詳細(xì)內(nèi)容，更多關(guān)于Java HashMap容量性能的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論