JDK的運行時常量池、字符串常量池、靜態常量池

首先匯總一下JDK的運行時常量池、字符串常量池、靜態常量池的功能及存儲結構。

一、JVM運行時內存結構

 在了解常量池之前我們先通過一張圖了解一下JVM的整個內存分布圖。下圖為JDK7的內存結構：

在上圖中JVM所管理的內存主要包括以下區域：程序計數器(Program Counter Register)、虛擬機棧(VM Stack)、本地方法棧(Native Method Stack)、方法區(Method Area)、堆(Heap)。

不同版本的JVM的內存結構有不同的變化，這些變化對我們今天要講的三個概念會有所影響，后面我們會逐一講解。

了解了JVM內存結構，那么運行時常量池、字符串常量池、靜態常量池對於的都位於JVM的什么區域呢？先來看看它們的定義及功能。

二、靜態常量池

Java程序要運行時，需要編譯器先將源代碼文件編譯成字節碼（.class)文件，然后在由JVM解釋執行。

class文件中除了有類的版本、字段、方法、接口等描述信息外,還有一項信息是常量池(Constant pool table)，用於存放編譯期生成的各種字面量和符號引用，這部分內容將在類加載后進入運行時常量池中存放。

靜態常量池就是上面說的class文件中的常量池。class常量池是在編譯時每個class文件中都存在。不同的符號信息放置在不同標志的常量表中。

常量池中存放的符號信息，在JVM執行指令時需要依賴使用。常量池中的所有項都具有如下通用格式：

cp_info {
    u1 tag;     //表示cp_info的單字節標記位
    u1 info[];  //兩個或更多的字節表示這個常量的信息，信息格式由tag的值確定
}

支持的類型信息如下：

以CONSTANT_Class為例，它用於表示類或者接口，格式如下：

CONSTANT_Class_info {
 u1 tag;       //這個值為CONSTANT_Class (7)
 u2 name_index;//一個index，表示一個索引，引用的是CONSTANT_UTF8_info
}

CONSTANT_Class_info類型是由一個tag和一個name_index組成。name_index中的index表示它是一個索引，引用的是CONSTANT_UTF8_info。

CONSTANT_Utf8_info用於表示字符常量的值，結構如下所示：

CONSTANT_Utf8_info {
 u1 tag;
 u2 length;
 u1 bytes[length];
}

tag表示為：CONSTANT_Utf8（1）；length指明了bytes[]數組的長度；bytes[]數組引用了上一個length作為其長度。字符常量采用改進過的UTF-8編碼表示。

對於靜態常量池我們需要知道它存在於編譯器，如果說與運行時有關的話，可以說運行時中的常量是JVM加載class文件之后進行分配的。

三、運行時常量池

運行時常量池就是將編譯后的類信息放入方法區中，也就是說它是方法區的一部分。

運行時常量池用來動態獲取類信息，包括：class文件元信息描述、編譯后的代碼數據、引用類型數據、類文件常量池等。

運行時常量池是在類加載完成之后，將每個class常量池中的符號引用值轉存到運行時常量池中。每個class都有一個運行時常量池，類在解析之后將符號引用替換成直接引用，與全局常量池中的引用值保持一致。

運行時常量池相對於class文件常量池的另外一個特性是具備動態性，java語言並不要求常量一定只有編譯器才產生，也就是並非預置入class文件中常量池的內容才能進入方法區運行時常量池，運行期間也可能將新的常量放入池中。

四、字符串常量池

字符串池里的內容是在類加載完成，經過驗證、准備階段之后存放在字符串常量池中。關於字符串常量池的具體實現我們這里先不展開，后面用專門的文章來進行講解。

字符串常量池的處理機制我們前面文章已經講到，只會存儲一份，被所有的類共享。基本流程是：創建字符串之前檢查常量池中是否存在，如果存在則獲取其引用，如果不存在則創建並存入，返回新對象引用。

字符串常量池隨着JDK版本的演化所在的位置也在不斷的變化，下面我們會專門用圖講解一下。

五、常量池內存位置演化

在JDK1.7之前運行時常量池邏輯包含字符串常量池存放在方法區, 此時hotspot虛擬機對方法區的實現為永久代。

在JDK1.7字符串常量池和靜態變量被從方法區拿到了堆中，運行時常量池剩下的還在方法區, 也就是hotspot中的永久代。

在JDK8 hotspot移除了永久代用元空間(Metaspace)取而代之, 這時候字符串常量池還在堆，運行時常量池還在方法區，只不過方法區的實現從永久代變成了元空間(Metaspace)。

通過上面的圖解，我們可以輕易得知在不同的版本中方法區及內部組成部分是在不斷變化的。

總結一下就是：

靜態變量處於編譯器，存在於class文件內，可通過javap verbose命令查看字符串合並時查看的是靜態常量池里面的內容；字符串常量池曾經屬於運行時常量池的一部分，位於方法區，但隨着JVM版本的演變，二者已經分開。在JDK8以后字符串常量池位於堆中，而運行時常量池位於方法區。

---

六、字符串常量池介紹

在 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不斷變長》。

2、討論 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

3、測試 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，還是使用默認值。

4、討論自建 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，沒必要。

5、小結

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

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

---

七、NEW STRING()創建幾個對象問題探討

1、常見面試問題

下面代碼中創建了幾個對象？

new String("abc");

答案眾說紛紜，有說創建了1個對象，也有說創建了2個對象。答案對，也不對，關鍵是要學到問題底層的原理。

2、底層原理分析

String的兩種初始化形式是有本質區別的

String str1 = "abc";  // 在常量池中

String str2 = new String("abc"); // 在堆上

當直接賦值時，字符串“abc”會被存儲在常量池中，只有1份，此時的賦值操作等於是創建0個或1個對象。如果常量池中已經存在了“abc”，那么不會再創建對象，直接將引用賦值給str1；如果常量池中沒有“abc”，那么創建一個對象，並將引用賦值給str1。

那么，通過new String(“abc”);的形式又是如何呢？答案是1個或2個。

當JVM遇到上述代碼時，會先檢索常量池中是否存在“abc”，如果不存在“abc”這個字符串，則會先在常量池中創建這個一個字符串。然后再執行new操作，會在堆內存中創建一個存儲“abc”的String對象，對象的引用賦值給str2。此過程創建了2個對象。

當然，如果檢索常量池時發現已經存在了對應的字符串，那么只會在堆內創建一個新的String對象，此過程只創建了1個對象。

在上述過程中檢查常量池是否有相同Unicode的字符串常量時，使用的方法便是String中的intern()方法。

public native String intern();

下面通過一個簡單的示意圖看一下String在內存中的兩種存儲模式。

上面的示意圖我們可以看到在堆內創建的String對象的char value[]屬性指向了常量池中的char value[]。

還是上面的示例，如果我們通過debug模式也能夠看到String的char value[]的引用地址。

圖中兩個String對象的value值的引用均為{char[3]@1355}，也就是說，雖然是兩個對象，但它們的value值均指向常量池中的同一個地址。當然，大家還可以拿一個復雜對象（Person）的字符串屬性（name）相同時的debug結果進行比對，結果是一樣的。

3、深入問法

如果面試官說程序的代碼只有下面一行，那么會創建幾個對象？

new String("abc");

答案是2個？

還真不一定。之所以單獨列出這個問題是想提醒大家一點：沒有直接的賦值操作（str=”abc”），並不代表常量池中沒有“abc”這個字符串。也就是說衡量創建幾個對象、常量池中是否有對應的字符串，不僅僅由你是否創建決定，還要看程序啟動時其他類中是否包含該字符串。

4、升級加碼

以下實例我們暫且不考慮常量池中是否已經存在對應字符串的問題，假設都不存在對應的字符串。

以下代碼會創建幾個對象：

String str = "abc" + "def";

上面的問題涉及到字符串常量重載“+”的問題，當一個字符串由多個字符串常量拼接成一個字符串時，它自己也肯定是字符串常量。字符串常量的“+”號連接Java虛擬機會在程序編譯期將其優化為連接后的值。

就上面的示例而言，在編譯時已經被合並成“abcdef”字符串，因此，只會創建1個對象。並沒有創建臨時字符串對象abc和def，這樣減輕了垃圾收集器的壓力。

我們通過javap查看class文件可以看到如下內容。

很明顯，字節碼中只有拼接好的abcdef。

針對上面的問題，我們再次升級一下，下面的代碼會創建幾個對象？

String str = "abc" + new String("def");

創建了4個，5個，還是6個對象？

4個對象的說法：常量池中分別有“abc”和“def”，堆中對象new String(“def”)和“abcdef”。

這種說法對嗎？不完全對，如果說上述代碼創建了幾個字符串對象，那么可以說是正確的。但上述的代碼Java虛擬機在編譯的時候同樣會優化，會創建一個StringBuilder來進行字符串的拼接，實際效果類似：

String s = new String("def");
new StringBuilder().append("abc").append(s).toString();

很顯然，多出了一個StringBuilder對象，那就應該是5個對象。

那么創建6個對象是怎么回事呢？有同學可能會想了，StringBuilder最后toString()之后的“abcdef”難道不在常量池存一份嗎？

這個還真沒有存，我們來看一下這段代碼：

@Test
public void testString3() {
    String s1 = "abc";
    String s2 = new String("def");
    String s3 = s1 + s2;
    String s4 = "abcdef";
    System.out.println(s3==s4); // false
}

按照上面的分析，如果s1+s2的結果在常量池中存了一份，那么s3中的value引用應該和s4中value的引用是一樣的才對。下面我們看一下debug的效果。

很明顯，s3和s4的值相同，但value值的地址並不相同。即便是將s3和s4的位置調整一下，效果也一樣。s4很明確是存在於常量池中，那么s3對應的值存儲在哪里呢？很顯然是在堆對象中。

我們來看一下StringBuilder的toString()方法是如何將拼接的結果轉化為字符串的：

@Override
public String toString() {
    // Create a copy, don't share the array
    return new String(value, 0, count);
}

很顯然，在toString方法中又新創建了一個String對象，而該String對象傳遞數組的構造方法來創建的：

public String(char value[], int offset, int count) 

也就是說，String對象的value值直接指向了一個已經存在的數組，而並沒有指向常量池中的字符串。

因此，上面的准確回答應該是創建了4個字符串對象和1個StringBuilder對象。

 

 

參考文章：

http://www.choupangxia.com/2020/08/28/jvm-string-pool

http://www.choupangxia.com/2020/08/28/java-string

http://www.choupangxia.com/2020/08/25/new-string