Java內(nèi)存分析（3）——String的Intern方法詳解

2019-11-06 06:18:06

字體：大中小

供稿：網(wǎng)友

原文地址:http://www.cnblogs.com/wxgblogs/p/5635099.html

引言

　　在 java 語言中有8中基本類型和一種比較特殊的類型String。這些類型為了使他們在運行過程中速度更快，更節(jié)省內(nèi)存，都提供了一種常量池的概念。常量池就類似一個JAVA系統(tǒng)級別提供的緩存。8種基本類型的常量池都是系統(tǒng)協(xié)調(diào)的，String類型的常量池比較特殊。它的主要使用方法有兩種：

直接使用雙引號聲明出來的String對象會直接存儲在常量池中。如果不是用雙引號聲明的String對象，可以使用String提供的intern方法。intern 方法會從字符串常量池中查詢當(dāng)前字符串是否存在，若不存在就會將當(dāng)前字符串放入常量池中一. intern 的實現(xiàn)原理

1.JAVA 代碼

/** * Returns a canonical rePResentation for the string object. * <p> * A pool of strings, initially empty, is maintained privately by the * class <code>String</code>. * <p> * When the intern method is invoked, if the pool already contains a * string equal to this <code>String</code> object as determined by * the {@link #equals(Object)} method, then the string from the pool is * returned. Otherwise, this <code>String</code> object is added to the * pool and a reference to this <code>String</code> object is returned. * <p> * It follows that for any two strings <code>s</code> and <code>t</code>, * <code>s.intern() == t.intern()</code> is <code>true</code> * if and only if <code>s.equals(t)</code> is <code>true</code>. * <p> * All literal strings and string-valued constant expressions are * interned. String literals are defined in section 3.10.5 of the * <cite>The Java? Language Specification</cite>. * * @return a string that has the same contents as this string, but is * guaranteed to be from a pool of unique strings. */ public native String intern();

　　String.intern方法中看到，這個方法是一個 native 的方法，但注釋寫的非常明了?！叭绻Ａ砍刂写嬖诋?dāng)前字符串, 就會直接返回當(dāng)前字符串. 如果常量池中沒有此字符串, 會將此字符串放入常量池中后, 再返回”。

2，native 代碼

　　在 jdk7后，Oracle 接管了 JAVA 的源碼后就不對外開放了，根據(jù) jdk 的主要開發(fā)人員聲明 openJdk7 和 jdk7 使用的是同一分主代碼，只是分支代碼會有些許的變動。所以可以直接跟蹤 openJdk7 的源碼來探究 intern 的實現(xiàn)。

native實現(xiàn)代碼:

/openjdk7/jdk/src/share/native/java/lang/String.c

Java_java_lang_String_intern(JNIEnv *env, jobject this){ return JVM_InternString(env, this);}/openjdk7/hotspot/src/share/vm/prims/jvm.h/** java.lang.String*/JNIEXPORT jstring JNICALLJVM_InternString(JNIEnv *env, jstring str);

/openjdk7/hotspot/src/share/vm/prims/jvm.cpp

// String support ///////////////////////////////////////////////////////////////////////////JVM_ENTRY(jstring, JVM_InternString(JNIEnv *env, jstring str)) JVMWrapper("JVM_InternString"); JvmtiVMObjectAllocEventCollector oam; if (str == NULL) return NULL; oop string = JNIHandles::resolve_non_null(str); oop result = StringTable::intern(string, CHECK_NULL); return (jstring) JNIHandles::make_local(env, result);JVM_END

/openjdk7/hotspot/src/share/vm/classfile/symbolTable.cpp

oop StringTable::intern(Handle string_or_null, jchar* name, int len, TRAPS) { unsigned int hashValue = java_lang_String::hash_string(name, len); int index = the_table()->hash_to_index(hashValue); oop string = the_table()->lookup(index, name, len, hashValue); // Found if (string != NULL) return string; // Otherwise, add to symbol to table return the_table()->basic_add(index, string_or_null, name, len, hashValue, CHECK_NULL);}

/openjdk7/hotspot/src/share/vm/classfile/symbolTable.cpp

oop StringTable::lookup(int index, jchar* name, int len, unsigned int hash) { for (HashtableEntry<oop>* l = bucket(index); l != NULL; l = l->next()) { if (l->hash() == hash) { if (java_lang_String::equals(l->literal(), name, len)) { return l->literal(); } } } return NULL;}

　　它的大體實現(xiàn)結(jié)構(gòu)就是:JAVA 使用 jni 調(diào)用c++實現(xiàn)的StringTable的intern方法, StringTable的intern方法跟Java中的HashMap的實現(xiàn)是差不多的, 只是不能自動擴容。默認(rèn)大小是1009。要注意的是，String的String Pool是一個固定大小的Hashtable，默認(rèn)值大小長度是1009，如果放進(jìn)String Pool的String非常多，就會造成Hash沖突嚴(yán)重，從而導(dǎo)致鏈表會很長，而鏈表長了后直接會造成的影響就是當(dāng)調(diào)用String.intern時性能會大幅下降。在 jdk6中StringTable是固定的，就是1009的長度，所以如果常量池中的字符串過多就會導(dǎo)致效率下降很快。在jdk7中，StringTable的長度可以通過一個參數(shù)指定：

-XX:StringTableSize=99991

二.jdk6 和 jdk7 下 intern 的區(qū)別

　　相信很多 JAVA 程序員都做做類似 String s = new String(“abc”)這個語句創(chuàng)建了幾個對象的題目。這種題目主要就是為了考察程序員對字符串對象的常量池掌握與否。上述的語句中是創(chuàng)建了2個對象，第一個對象是”abc”字符串存儲在常量池中，第二個對象在JAVA Heap中的 String 對象。

public static void main(String[] args) { String s = new String("1"); s.intern(); String s2 = "1"; System.out.println(s == s2); String s3 = new String("1") + new String("1"); s3.intern(); String s4 = "11"; System.out.println(s3 == s4);}

打印結(jié)果是

jdk6 下false false jdk7 下false true 　　　　具體為什么稍后再解釋，然后將s3.intern();語句下調(diào)一行，放到String s4 = “11”;后面。將s.intern(); 放到String s2 = “1”;后面。是什么結(jié)果呢

public static void main(String[] args) { String s = new String("1"); String s2 = "1"; s.intern(); System.out.println(s == s2); String s3 = new String("1") + new String("1"); String s4 = "11"; s3.intern(); System.out.println(s3 == s4);}

打印結(jié)果為：

jdk6 下false false jdk7 下false false

1.jdk6中的解釋

這里寫圖片描述　　注：圖中綠色線條代表 string 對象的內(nèi)容指向。黑色線條代表地址指向。

　　如上圖所示。首先說一下 jdk6中的情況，在 jdk6中上述的所有打印都是 false 的，因為 jdk6中的常量池是放在 Perm 區(qū)中的，Perm區(qū)和正常的 JAVA Heap 區(qū)域是完全分開的。上面說過如果是使用引號聲明的字符串都是會直接在字符串常量池中生成，而 new 出來的 String 對象是放在 JAVA Heap 區(qū)域。所以拿一個 JAVA Heap 區(qū)域的對象地址和字符串常量池的對象地址進(jìn)行比較肯定是不相同的，即使調(diào)用String.intern方法也是沒有任何關(guān)系的。

2.jdk7中的解釋

　　在 Jdk6 以及以前的版本中，字符串的常量池是放在堆的Perm區(qū)的，Perm區(qū)是一個類靜態(tài)的區(qū)域，主要存儲一些加載類的信息，常量池，方法片段等內(nèi)容，默認(rèn)大小只有4m，一旦常量池中大量使用 intern 是會直接產(chǎn)生java.lang.OutOfMemoryError:PermGen space錯誤的。在 jdk7 的版本中，字符串常量池已經(jīng)從Perm區(qū)移到正常的Java Heap區(qū)域了。為什么要移動，Perm 區(qū)域太小是一個主要原因，當(dāng)然據(jù)消息稱jdk8已經(jīng)直接取消了Perm區(qū)域，而新建立了一個元區(qū)域。應(yīng)該是jdk開發(fā)者認(rèn)為Perm區(qū)域已經(jīng)不適合現(xiàn)在 JAVA 的發(fā)展了。正式因為字符串常量池移動到JAVA Heap區(qū)域后，再來解釋為什么會有上述的打印結(jié)果。這里寫圖片描述

在第一段代碼中，先看 s3和s4字符串。String s3 = new String(“1”) + new String(“1”);，這句代碼中現(xiàn)在生成了2最終個對象，是字符串常量池中的“1” 和 JAVA Heap中的 s3引用指向的對象。中間還有2個匿名的new String(“1”)我們不去討論它們。此時s3引用對象內(nèi)容是”11″，但此時常量池中是沒有 “11”對象的。

接下來s3.intern();這一句代碼，是將 s3中的”11”字符串放入String 常量池中，因為此時常量池中不存在”11”字符串，因此常規(guī)做法是跟 jdk6 圖中表示的那樣，在常量池中生成一個”11”的對象，關(guān)鍵點是 jdk7 中常量池不在Perm區(qū)域了，這塊做了調(diào)整。常量池中不需要再存儲一份對象了，可以直接存儲堆中的引用。這份引用指向s3引用的對象。也就是說引用地址是相同的。

最后String s4 = “11”; 這句代碼中”11″是顯示聲明的，因此會直接去常量池中創(chuàng)建，創(chuàng)建的時候發(fā)現(xiàn)已經(jīng)有這個對象了，此時也就是指向s3引用對象的一個引用。所以s4引用就指向和s3一樣了。因此最后的比較 s3 == s4 是 true。

再看s和 s2 對象。String s = new String(“1”); 第一句代碼，生成了2個對象。常量池中的“1” 和 JAVA Heap 中的字符串對象。s.intern(); 這一句是 s 對象去常量池中尋找后發(fā)現(xiàn) “1” 已經(jīng)在常量池里了。接下來String s2 = “1”; 這句代碼是生成一個 s2的引用指向常量池中的“1”對象。結(jié)果就是 s 和 s2 的引用地址明顯不同。圖中畫的很清晰。這里寫圖片描述

來看第二段代碼，從上邊第二幅圖中觀察。第一段代碼和第二段代碼的改變就是 s3.intern(); 的順序是放在String s4 = “11”;后了。這樣，首先執(zhí)行String s4 = “11”;聲明 s4 的時候常量池中是不存在“11”對象的，執(zhí)行完畢后，“11“對象是 s4 聲明產(chǎn)生的新對象。然后再執(zhí)行s3.intern();時，常量池中“11”對象已經(jīng)存在了，因此 s3 和 s4 的引用是不同的。第二段代碼中的 s 和 s2 代碼中，s.intern();，這一句往后放也不會有什么影響了，因為對象池中在執(zhí)行第一句代碼String s = new String(“1”);的時候已經(jīng)生成“1”對象了。下邊的s2聲明都是直接從常量池中取地址引用的。 s 和 s2 的引用地址是不會相等的。小結(jié)

　　從上述的例子代碼可以看出 jdk7 版本對 intern 操作和常量池都做了一定的修改。主要包括2點：

將String常量池從Perm區(qū)移動到了Java Heap區(qū) String#intern 方法時，如果存在堆中的對象，會直接保存對象的引用，而不會重新創(chuàng)建對象。

三.使用 intern

1.intern 正確使用例子

　　接下來我們來看一下一個比較常見的使用String#intern方法的例子。

static final int MAX = 1000 * 10000;static final String[] arr = new String[MAX];public static void main(String[] args) throws Exception { Integer[] DB_DATA = new Integer[10]; Random random = new Random(10 * 10000); for (int i = 0; i < DB_DATA.length; i++) { DB_DATA[i] = random.nextInt(); } long t = System.currentTimeMillis(); for (int i = 0; i < MAX; i++) { //arr[i] = new String(String.valueOf(DB_DATA[i % DB_DATA.length])); arr[i] = new String(String.valueOf(DB_DATA[i % DB_DATA.length])).intern(); } System.out.println((System.currentTimeMillis() - t) + "ms"); System.gc();}

　　運行的參數(shù)是：-Xmx2g -Xms2g -Xmn1500M 上述代碼是一個演示代碼，其中有兩條語句不一樣，一條是使用 intern，一條是未使用 intern。結(jié)果如下圖

2160ms

這里寫圖片描述 826ms

　　通過上述結(jié)果，我們發(fā)現(xiàn)不使用 intern 的代碼生成了1000w 個字符串，占用了大約640m 空間。使用了 intern 的代碼生成了1345個字符串，占用總空間 133k 左右。其實通過觀察程序中只是用到了10個字符串，所以準(zhǔn)確計算后應(yīng)該是正好相差100w 倍。雖然例子有些極端，但確實能準(zhǔn)確反應(yīng)出 intern 使用后產(chǎn)生的巨大空間節(jié)省。

細(xì)心的同學(xué)會發(fā)現(xiàn)使用了 intern 方法后時間上有了一些增長。這是因為程序中每次都是用了 new String 后，然后又進(jìn)行 intern 操作的耗時時間，這一點如果在內(nèi)存空間充足的情況下確實是無法避免的，但我們平時使用時，內(nèi)存空間肯定不是無限大的，不使用 intern 占用空間導(dǎo)致 jvm 垃圾回收的時間是要遠(yuǎn)遠(yuǎn)大于這點時間的。畢竟這里使用了1000w次intern 才多出來1秒鐘多的時間。

2，intern 不當(dāng)使用

　　看過了 intern 的使用和 intern 的原理等，我們來看一個不當(dāng)使用 intern 操作導(dǎo)致的問題。

　　在使用 fastjson 進(jìn)行接口讀取的時候，我們發(fā)現(xiàn)在讀取了近70w條數(shù)據(jù)后，我們的日志打印變的非常緩慢，每打印一次日志用時30ms左右，如果在一個請求中打印2到3條日志以上會發(fā)現(xiàn)請求有一倍以上的耗時。在重新啟動 jvm 后問題消失。繼續(xù)讀取接口后，問題又重現(xiàn)。接下來我們看一下出現(xiàn)問題的過程。

1，根據(jù) log4j 打印日志查找問題原因

在使用log4j#info打印日志的時候時間非常長。所以使用 housemd 軟件跟蹤 info 方法的耗時堆棧。

trace SLF4JLogger. trace AbstractLoggerWrapper: trace AsyncLogger

org/apache/logging/log4j/core/async/AsyncLogger.actualAsyncLog(RingBufferLogEvent) sun.misc.Launcher$AppClassLoader@109aca82 1 1ms org.apache.logging.log4j.core.async.AsyncLogger@19de86bb org/apache/logging/log4j/core/async/AsyncLogger.location(String) sun.misc.Launcher$AppClassLoader@109aca82 1 30ms org.apache.logging.log4j.core.async.AsyncLogger@19de86bb org/apache/logging/log4j/core/async/AsyncLogger.log(Marker, String, Level, Message, Throwable) sun.misc.Launcher$AppClassLoader@109aca82 1 61ms org.apache.logging.log4j.core.async.AsyncLogger@19de86bb代碼出在 AsyncLogger.location 這個方法上. 里邊主要是調(diào)用了 return Log4jLogEvent.calcLocation(fqcnOfLogger);和Log4jLogEvent.calcLocation()

Log4jLogEvent.calcLocation()的代碼如下:

public static StackTraceElement calcLocation(final String fqcnOfLogger) { if (fqcnOfLogger == null) { return null; } final StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace(); boolean next = false; for (final StackTraceElement element : stackTrace) { final String className = element.getClassName(); if (next) { if (fqcnOfLogger.equals(className)) { continue; } return element; } if (fqcnOfLogger.equals(className)) { next = true; } else if (NOT_AVAIL.equals(className)) { break; } } return null; }

　　經(jīng)過跟蹤發(fā)現(xiàn)是 Thread.currentThread().getStackTrace(); 的問題。

2, 跟蹤Thread.currentThread().getStackTrace()的 native 代碼，驗證String#intern

　　Thread.currentThread().getStackTrace();native的方法:

public StackTraceElement[] getStackTrace() { if (this != Thread.currentThread()) { // check for getStackTrace permission SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkPermission( SecurityConstants.GET_STACK_TRACE_PERMISSION); } // optimization so we do not call into the vm for threads that // have not yet started or have terminated if (!isAlive()) { return EMPTY_STACK_TRACE; } StackTraceElement[][] stackTraceArray = dumpThreads(new Thread[] {this}); StackTraceElement[] stackTrace = stackTraceArray[0]; // a thread that was alive during the previous isAlive call may have // since terminated, therefore not having a stacktrace. if (stackTrace == null) { stackTrace = EMPTY_STACK_TRACE; } return stackTrace; } else { // Don't need JVM help for current thread return (new Exception()).getStackTrace(); } }

下載 openJdk7的源碼查詢 jdk 的 native 實現(xiàn)代碼，列表如下【這里因為篇幅問題，不詳細(xì)羅列涉及到的代碼，有興趣的可以根據(jù)文件名稱和行號查找相關(guān)代碼】：

/openjdk7/jdk/src/share/native/java/lang/Thread.c /openjdk7/hotspot/src/share/vm/prims/jvm.h line:294: /openjdk7/hotspot/src/share/vm/prims/jvm.cpp line:4382-4414: /openjdk7/hotspot/src/share/vm/services/threadService.cpp line:235-267: /openjdk7/hotspot/src/share/vm/services/threadService.cpp line:566-577: /openjdk7/hotspot/src/share/vm/classfile/javaClasses.cpp line:1635-[1651,1654,1658]:

完成跟蹤了底層的 jvm 源碼后發(fā)現(xiàn)，是下邊的三條代碼引發(fā)了整個程序的變慢問題。

oop classname = StringTable::intern((char*) str, CHECK_0); oop methodname = StringTable::intern(method->name(), CHECK_0); oop filename = StringTable::intern(source, CHECK_0);

這三段代碼是獲取類名、方法名、和文件名。因為類名、方法名、文件名都是存儲在字符串常量池中的，所以每次獲取它們都是通過String#intern方法。但沒有考慮到的是默認(rèn)的 StringPool 的長度是1009且不可變的。因此一旦常量池中的字符串達(dá)到的一定的規(guī)模后，性能會急劇下降。

3,fastjson 不當(dāng)使用 String#intern

導(dǎo)致這個 intern 變慢的原因是因為 fastjson 對String#intern方法的使用不當(dāng)造成的。跟蹤 fastjson 中的實現(xiàn)代碼發(fā)現(xiàn)，

com.alibaba.fastjson.parser.JSONScanner#scanFieldSymbol()：

if (ch == '/"') { bp = index; this.ch = ch = buf[bp]; strVal = symbolTable.addSymbol(buf, start, index - start - 1, hash); break;}

com.alibaba.fastjson.parser.SymbolTable#addSymbol():

/** * Constructs a new entry from the specified symbol information and next entry reference. */public Entry(char[] ch, int offset, int length, int hash, Entry next){ characters = new char[length]; System.arraycopy(ch, offset, characters, 0, length); symbol = new String(characters).intern(); this.next = next; this.hashCode = hash; this.bytes = null;}

fastjson 中對所有的 json 的 key 使用了 intern 方法，緩存到了字符串常量池中，這樣每次讀取的時候就會非?？欤蟠鬁p少時間和空間。而且 json 的 key 通常都是不變的。這個地方?jīng)]有考慮到大量的 json key 如果是變化的，那就會給字符串常量池帶來很大的負(fù)擔(dān)。

這個問題 fastjson 在1.1.24版本中已經(jīng)將這個漏洞修復(fù)了。程序加入了一個最大的緩存大小，超過這個大小后就不會再往字符串常量池中放了。

[1.1.24版本的com.alibaba.fastjson.parser.SymbolTable#addSymbol() Line:113]代碼

public static final int MAX_SIZE = 1024;if (size >= MAX_SIZE) { return new String(buffer, offset, len);}

這個問題是70w 數(shù)據(jù)量時候的引發(fā)的，如果是幾百萬的數(shù)據(jù)量的話可能就不只是30ms 的問題了。因此在使用系統(tǒng)級提供的String#intern方式一定要慎重！

五.總結(jié)

　　本文大體的描述了 String#intern和字符串常量池的日常使用，jdk 版本的變化和String#intern方法的區(qū)別，以及不恰當(dāng)使用導(dǎo)致的危險等內(nèi)容，讓大家對系統(tǒng)級別的 String#intern有一個比較深入的認(rèn)識。讓我們在使用和接觸它的時候能避免出現(xiàn)一些 bug，增強系統(tǒng)的健壯性。

不忘初心，方得始終

上一篇：java實現(xiàn)快速排序

下一篇：Java并發(fā)編程 - 基礎(chǔ)