JVM針對字符串常量池優化的示例分析

JVM針對字符串常量池優化的示例分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

在 Java 世界中，構造一個 Java 對象是一個相對比較重的活，而且還需要垃圾回收，而緩存池就是為了緩解這個問題的。

我們來看下基礎類型的包裝類的緩存，Integer 默認緩存 -128 ~ 127 區間的值，Long 和 Short 也是緩存了這個區間的值，Byte 只能表示 -127 ~ 128 范圍的值，全部緩存了，Character 緩存了 0 ~ 127 的值。Float 和 Double 沒有緩存的意義。

Integer 可通過設置 java.lang.Integer.IntegerCache.high 擴大緩存區間

String 不是基礎類型，但是它也有同樣的機制，通過 String Pool 來緩存 String 對象。假設 "Java" 這個字符串我們會在應用程序中使用多次，我們肯定不希望在每次使用到的時候，都重新在堆中創建一個新的對象。

當然，之所以 Integer、Long、String 這些類的對象可以緩存，是因為它們是不可變類

基礎類型包裝類的緩存池使用一個數組進行緩存，而 String 類型，JVM 內部使用 HashTable 進行緩存，我們知道，HashTable 的結構是一個數組，數組中每個元素是一個鏈表。和我們平時使用的 HashTable 不同，JVM 內部的這個 HashTable 是不可以動態擴容的。

1

創建和回收 當我們在程序中使用雙引號來表示一個字符串時，這個字符串就會進入到 String Pool 中。當然，這里說的是已被加載到 JVM 中的類。

這是一個不夠嚴謹的說法，請參見評論區的討論。

另外，就是 String#intern() 方法，這個方法的作用就是：

如果字符串未在 Pool 中，那么就往 Pool 中增加一條記錄，然后返回 Pool 中的引用。 如果已經在 Pool 中，直接返回 Pool 中的引用。 只要 String Pool 中的 String 對象對于 GC Roots 來說不可達，那么它們就是可以被回收的。

如果 Pool 中對象過多，可能導致 YGC 變長，因為 YGC 的時候，需要掃描 String Pool，可以看看笨神大佬的文章《JVM源碼分析之String.intern()導致的YGC不斷變長》。

討論 String Pool 的實現 1、首先，我們先考慮 String Pool 的空間問題。

在 Java 6 中，String Pool 置于 PermGen Space 中，PermGen 有一個問題，那就是它是一個固定大小的區域，雖然我們可以通過 -XX:MaxPermSize=N 來設置永久代的空間大小，但是不管我們設置成多少，它終歸是固定的。

所以，在 Java 6 中，我們應該盡量小心使用 String.intern() 方法，否則容易導致 OutOfMemoryError。

到了 Java 7，大佬們已經著手去掉 PermGen Space 了，首先，就是將 String Pool 移到了堆中。

把 String Pool 放到堆中，即使堆的大小也是固定的，但是這個時候，對于應用調優工作，只需要調整堆大小就行了。

到了 Java 8，PermGen 已經被徹底廢棄，出現了堆外內存區域 MetaSpace，String Pool 相應的從堆轉移到了 MetaSpace 中。

在 Java 8 中，String Pool 依然還是在 Heap Space 中。感謝評論區的讀者指出錯誤。大家可以看一下我后面寫的關于 MetaSpace 的文章，那篇文章深入分析了 MetaSpace 的構成。

2、其次，我們再討論 String Pool 的實現問題。

前面我們說了 String Pool 使用一個 HashTable 來實現，這個 HashTable 不可以擴容，也就意味著極有可能出現單個 bucket 中的鏈表很長，導致性能降低。

在 Java 6 中，這個 HashTable 固定的 bucket 數量是 1009，后來添加了選項（-XX:StringTableSize=N）可以配置這個值。到 Java 7（7u40），大佬們提高了這個默認值到 60013，Java 8 依然也是使用這個值，對于絕大部分應用來說，這個值是足夠用的。當然，如果你會在代碼中大量使用 String#intern()，那么有必要手動設置一下這個值。

為什么是 1009，而不是 1000 或者 1024？因為 1009 是質數，有利于達到更好的散列。60013 同理。

JVM 內部的 HashTable 是不擴容的，但是不代表它不 rehash，它會在發現散列不均勻的時候進行 rehash，這里不展開介紹。

3、觀察 String Pool 的使用情況。

JVM 提供了 -XX:+PrintStringTableStatistics 啟動參數來幫助我們獲取統計數據。

遺憾的是，只有在 JVM 退出的時候，JVM 才會將統計數據打印出來，JVM 沒有提供接口給我們實時獲取統計數據。

SymbolTable statistics: Number of buckets : 20011 = 160088 bytes, avg 8.000 Number of entries : 10923 = 262152 bytes, avg 24.000 Number of literals : 10923 = 425192 bytes, avg 38.926 Total footprint : = 847432 bytes Average bucket size : 0.546 Variance of bucket size : 0.545 Std. dev. of bucket size: 0.738 Maximum bucket size : 6

看下面這部分：

StringTable statistics: Number of buckets : 60003 = 480024 bytes, avg 8.000 Number of entries : 4000774 = 96018576 bytes, avg 24.000 Number of literals : 4000774 = 1055252184 bytes, avg 263.762 Total footprint : = 1151750784 bytes Average bucket size : 66.676 Variance of bucket size : 19.843 Std. dev. of bucket size: 4.455 Maximum bucket size : 84

統計數據中包含了 buckets 的數量，總的 String 對象的數量，占用的總空間，單個 bucket 的鏈表平均長度和最大長度等。

上面的數據是在 Java 8 的環境中打印出來的，Java 7 的信息稍微少一些，主要是沒有 footprint 的數據：

StringTable statistics: Number of buckets : 60003 Average bucket size : 67 Variance of bucket size : 20 Std. dev. of bucket size: 4 Maximum bucket size : 84 測試 String Pool 的性能 接下來，我們來跑個測試，測試下 String Pool 的性能問題，并討論 -XX:StringTableSize=N 參數的作用。

我們將使用 String#intern() 往字符串常量池中添加 400萬 個不同的長字符串。

package com.javadoop;

import java.lang.ref.WeakReference; import java.util.ArrayList; import java.util.List; import java.util.WeakHashMap;

public class StringTest {

public static void main(String[] args) {
    test(4000000);
}

private static void test(int cnt) {
    final List<String> lst = new ArrayList<String>(1024);
    long start = System.currentTimeMillis();
    for (int i = 0; i < cnt; ++i) {
        final String str = "Very very very very very very very very very very very very very very " +
                "very long string: " + i;
        lst.add(str.intern());

        if (i % 200000 == 0) {
            System.out.println(i + 200000 + "; time = " + (System.currentTimeMillis() - start) / 1000.0 + " sec");
            start = System.currentTimeMillis();
        }
    }
    System.out.println("Total length = " + lst.size());
}

} 我們每插入 20萬 條數據，輸出一次耗時。

編譯

javac -d . StringTest.java

使用默認 table size (60013) 運行一次

java -Xms2g -Xmx2g com.javadoop.StringTest

設置 table size 為 400031，再運行一次

java -Xms2g -Xmx2g -XX:StringTableSize=400031 com.javadoop.StringTest 2

從左右兩部分數據可以很直觀看出來，插入的性能主要取決于鏈表的平均長度。當鏈表平均長度為 10 的時候，我們看到性能是幾乎沒有任何損失的。

還是那句話，根據自己的實際情況，考慮是否要設置 -XX:StringTableSize=N，還是使用默認值。

討論自建 String Pool 這一節我們來看下自己使用 HashMap 來實現 String Pool。

這里我們需要使用 WeakReference：

private static final WeakHashMap<String, WeakReference<String>> pool = new WeakHashMap<String, WeakReference<String>>(1024);

private static String manualIntern(final String str) { final WeakReference<String> cached = pool.get(str); if (cached != null) { final String value = cached.get(); if (value != null) { return value; } } pool.put(str, new WeakReference<String>(str)); return str; } 我們使用 1000 * 1000 * 1000 作為入參 cnt 的值進行測試，分別測試 [1] 和 [2]：

private static void test(int cnt) { final List<String> lst = new ArrayList<String>(1024); long start = System.currentTimeMillis(); for (int i = 0; i < cnt; ++i) { // [1] lst.add(String.valueOf(i).intern()); // [2] // lst.add(manualIntern(String.valueOf(i)));

    if (i % 200000 == 0) {
        System.out.println(i + 200000 + "; time = " + (System.currentTimeMillis() - start) / 1000.0 + " sec");
        start = System.currentTimeMillis();
    }
}
System.out.println("Total length = " + lst.size());

} 測試結果，2G 的堆大小，如果使用 String#intern()，大概在插入 3000萬 數據的時候，開始進入大量的 FullGC。

而使用自己寫的 manualIntern()，大概到 1400萬 的時候，就已經不行了。

沒什么結論，如果要說點什么的話，那就是不要自建 String Pool，沒必要。

記住有兩個 JVM 參數可以設置：-XX:StringTableSize=N、-XX:+PrintStringTableStatistics

StringTableSize，在 Java 6 中，是 1009；在 Java 7 和 Java 8 中，默認都是 60013，如果有必要請自行擴大這個值。

看完上述內容，你們掌握JVM針對字符串常量池優化的示例分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！