本文將介紹 HotSpot 中的 String Pool，字符串常量池。相對是一篇比較簡單的文章，大家花幾分鐘就看完了。
在 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 是不可以動態擴容的。
創建和回收
當我們在程序中使用雙引號來表示一個字符串時，這個字符串就會進入到 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 中。感謝評論區的讀者指出錯誤。
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.000Number of entries : 10923 = 262152 bytes, avg 24.000Number of literals : 10923 = 425192 bytes, avg 38.926Total footprint : = 847432 bytesAverage bucket size : 0.546Variance of bucket size : 0.545Std. dev. of bucket size: 0.738Maximum bucket size : 6## 看下面這部分：StringTable statistics:Number of buckets : 60003 = 480024 bytes, avg 8.000Number of entries : 4000774 = 96018576 bytes, avg 24.000Number of literals : 4000774 = 1055252184 bytes, avg 263.762Total footprint : = 1151750784 bytesAverage bucket size : 66.676Variance of bucket size : 19.843Std. dev. of bucket size: 4.455Maximum bucket size : 84
統計數據中包含了 buckets 的數量，總的 String 對象的數量，占用的總空間，單個 bucket 的鏈表平均長度和最大長度等。
上面的數據是在 Java 8 的環境中打印出來的，Java 7 的信息稍微少一些，主要是沒有 footprint 的數據：
StringTable statistics:Number of buckets : 60003Average bucket size : 67Variance of bucket size : 20Std. dev. of bucket size: 4Maximum 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
從左右兩部分數據可以很直觀看出來，插入的性能主要取決于鏈表的平均長度。當鏈表平均長度為 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，如果有必要請自行擴大這個值。
