String字符串是系統里最常用的類型之一，在系統中占據了很大的內存，因此，高效地使用字符串，對系統的性能有較好的提升。
針對字符串的優化，我在工作與學習過程總結了以下三種方案作分享：
一.優化構建的超大字符串
驗證環境：jdk1.8
反編譯工具：jad
1.下載反編譯工具jad，百度雲盤下載：
鏈接：https://pan.baidu.com/s/1TK1_N769NqtDtLn28jR-Xg
提取碼：ilil
2.驗證
先執行一段例子1代碼：
執行完成后，用反編譯工具jad進行反編譯：jad -o -a -s d.java test.class
1 public class test3 { 2 public static void main(String[] args) { 3 String str="ab"+"cd"+"ef"+"123"; 4 } 5 }
反編譯后的代碼：
1 // Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov. 2 // Jad home page: http://www.kpdus.com/jad.html 3 // Decompiler options: packimports(3) annotate 4 // Source File Name: test.java 5 package example; 6 public class test 7 { 8 public test() 9 { 10 // 0 0:aload_0 11 // 1 1:invokespecial #1 <Method void Object()> 12 // 2 4:return 13 } 14 public static void main(String args[]) 15 { 16 String str = "abcdef123"; 17 // 0 0:ldc1 #2 <String "abcdef123"> 18 // 1 2:astore_1 19 // 2 3:return 20 } 21 }
案例2：
1 public class test1 { 2 public static void main(String[] args) 3 { 4 String s = "abc"; 5 String ss = "ok" + s + "xyz" + 5; 6 System.out.println(ss); 7 } 8 }
用反編譯工具jad執行jad -o -a -s d.java test1.class進行反編譯后：
1 // Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov. 2 // Jad home page: http://www.kpdus.com/jad.html 3 // Decompiler options: packimports(3) annotate 4 // Source File Name: test1.java 5 6 package example; 7 8 import java.io.PrintStream; 9 10 public class test1 11 { 12 public test1() 13 { 14 // 0 0:aload_0 15 // 1 1:invokespecial #1 <Method void Object()> 16 // 2 4:return 17 } 18 public static void main(String args[]) 19 { 20 String s = "abc"; 21 // 0 0:ldc1 #2 <String "abc"> 22 // 1 2:astore_1 23 String ss = (new StringBuilder()).append("ok").append(s).append("xyz").append(5).toString(); 24 // 2 3:new #3 <Class StringBuilder> 25 // 3 6:dup 26 // 4 7:invokespecial #4 <Method void StringBuilder()> 27 // 5 10:ldc1 #5 <String "ok"> 28 // 6 12:invokevirtual #6 <Method StringBuilder StringBuilder.append(String)> 29 // 7 15:aload_1 30 // 8 16:invokevirtual #6 <Method StringBuilder StringBuilder.append(String)> 31 // 9 19:ldc1 #7 <String "xyz"> 32 // 10 21:invokevirtual #6 <Method StringBuilder StringBuilder.append(String)> 33 // 11 24:iconst_5 34 // 12 25:invokevirtual #8 <Method StringBuilder StringBuilder.append(int)> 35 // 13 28:invokevirtual #9 <Method String StringBuilder.toString()> 36 // 14 31:astore_2 37 System.out.println(ss); 38 // 15 32:getstatic #10 <Field PrintStream System.out> 39 // 16 35:aload_2 40 // 17 36:invokevirtual #11 <Method void PrintStream.println(String)> 41 // 18 39:return 42 } 43 }
根據反編譯結果，可以看到內部其實是通過StringBuilder進行字符串拼接的。
再來執行例3的代碼：
1 public class test2 { 2 public static void main(String[] args) { 3 String s = ""; 4 Random rand = new Random(); 5 for (int i = 0; i < 10; i++) { 6 s = s + rand.nextInt(1000) + " "; 7 } 8 System.out.println(s); 9 } 10 }
用反編譯工具jad執行jad -o -a -s d.java test2.class進行反編譯后，發現其內部同樣是通過StringBuilder來進行拼接的：
1 // Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov. 2 // Jad home page: http://www.kpdus.com/jad.html 3 // Decompiler options: packimports(3) annotate 4 // Source File Name: test2.java 5 package example; 6 import java.io.PrintStream; 7 import java.util.Random; 8 public class test2 9 { 10 public test2() 11 { 12 // 0 0:aload_0 13 // 1 1:invokespecial #1 <Method void Object()> 14 // 2 4:return 15 } 16 public static void main(String args[]) 17 { 18 String s = ""; 19 // 0 0:ldc1 #2 <String ""> 20 // 1 2:astore_1 21 Random rand = new Random(); 22 // 2 3:new #3 <Class Random> 23 // 3 6:dup 24 // 4 7:invokespecial #4 <Method void Random()> 25 // 5 10:astore_2 26 for(int i = 0; i < 10; i++) 27 //* 6 11:iconst_0 28 //* 7 12:istore_3 29 //* 8 13:iload_3 30 //* 9 14:bipush 10 31 //* 10 16:icmpge 55 32 s = (new StringBuilder()).append(s).append(rand.nextInt(1000)).append(" ").toString(); 33 // 11 19:new #5 <Class StringBuilder> 34 // 12 22:dup 35 // 13 23:invokespecial #6 <Method void StringBuilder()> 36 // 14 26:aload_1 37 // 15 27:invokevirtual #7 <Method StringBuilder StringBuilder.append(String)> 38 // 16 30:aload_2 39 // 17 31:sipush 1000 40 // 18 34:invokevirtual #8 <Method int Random.nextInt(int)> 41 // 19 37:invokevirtual #9 <Method StringBuilder StringBuilder.append(int)> 42 // 20 40:ldc1 #10 <String " "> 43 // 21 42:invokevirtual #7 <Method StringBuilder StringBuilder.append(String)> 44 // 22 45:invokevirtual #11 <Method String StringBuilder.toString()> 45 // 23 48:astore_1 46 47 // 24 49:iinc 3 1 48 //* 25 52:goto 13 49 System.out.println(s); 50 // 26 55:getstatic #12 <Field PrintStream System.out> 51 // 27 58:aload_1 52 // 28 59:invokevirtual #13 <Method void PrintStream.println(String)> 53 // 29 62:return 54 } 55 }
綜上案例分析，發現字符串進行“+”拼接時，內部有以下幾種情況：
1.“+”直接拼接的是常量變量，如"ab"+"cd"+"ef"+"123"，內部編譯就把幾個連接成一個常量字符串處理；
2. “+”拼接的含變量字符串，如案例2："ok" + s + "xyz" + 5，內部編譯其實是new 一個StringBuilder來進行來通過append進行拼接；
3.案例3循環過程，實質也是“+”拼接含變量字符串，因此，內部編譯時，也會創建StringBuilder來進行拼接。
對比三種情況，發現第三種情況每次做循環，都會新創建一個StringBuilder對象，這會增加系統的內存，反過來就會降低系統性能。
因此，在做字符串拼接時，單線程環境下，可以顯性使用StringBuilder來進行拼接，避免每循環一次就new一個StringBuilder對象；在多線程環境下，可以使用線程安全的StringBuffer，但涉及到鎖競爭，StringBuffer性能會比StringBuilder差一點。
這樣，起到在字符串拼接時的優化效果。
2.如何使用String.intern節省內存？
在回答這個問題之前，可以先對一段代碼進行測試：
1.首先在idea設置-XX:+PrintGCDetails -Xmx6G -Xmn3G，用來打印GC日志信息，設置如下圖所示：
2.執行以下例子代碼：
未使用intern的GC日志：
1 public class test4 { 2 public static void main(String[] args) { 3 final int MAX=10000000; 4 System.out.println("不用intern："+notIntern(MAX)); 5 // System.out.println("使用intern："+intern(MAX)); 6 } 7 private static long notIntern(int MAX){ 8 long start = System.currentTimeMillis(); 9 for (int i = 0; i < MAX; i++) { 10 int j = i % 100; 11 String str = String.valueOf(j); 12 } 13 return System.currentTimeMillis() - start; 14 } 15 /* 16 private static long intern(int MAX){ 17 long start = System.currentTimeMillis(); 18 for (int i = 0; i < MAX; i++) { 19 int j = i % 100; 20 String str = String.valueOf(j).intern(); 21 } 22 return System.currentTimeMillis() - start; 23 }*/ 24
1 不用intern：354 2 [GC (System.gc()) [PSYoungGen: 377487K->760K(2752512K)] 377487K->768K(2758656K), 0.0009102 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 3 [Full GC (System.gc()) [PSYoungGen: 760K->0K(2752512K)] [ParOldGen: 8K->636K(6144K)] 768K->636K(2758656K), [Metaspace: 3278K->3278K(1056768K)], 0.0051214 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 4 Heap 5 PSYoungGen total 2752512K, used 23593K [0x0000000700000000, 0x00000007c0000000, 0x00000007c0000000) 6 eden space 2359296K, 1% used [0x0000000700000000,0x000000070170a548,0x0000000790000000) 7 from space 393216K, 0% used [0x0000000790000000,0x0000000790000000,0x00000007a8000000) 8 to space 393216K, 0% used [0x00000007a8000000,0x00000007a8000000,0x00000007c0000000) 9 ParOldGen total 6144K, used 636K [0x0000000640000000, 0x0000000640600000, 0x0000000700000000) 10 object space 6144K, 10% used [0x0000000640000000,0x000000064009f2f8,0x0000000640600000) 11 Metaspace used 3284K, capacity 4500K, committed 4864K, reserved 1056768K 12 class space used 359K, capacity 388K, committed 512K, reserved 1048576K
根據打印的日志分析：沒有使用intern情況下，執行時間為354ms，占用內存為24229k;
使用intern的GC日志：
1 使用intern：1515 2 [GC (System.gc()) [PSYoungGen: 613417K->1144K(2752512K)] 613417K->1152K(2758656K), 0.0012530 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 3 [Full GC (System.gc()) [PSYoungGen: 1144K->0K(2752512K)] [ParOldGen: 8K->965K(6144K)] 1152K->965K(2758656K), [Metaspace: 3780K->3780K(1056768K)], 0.0079962 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 4 Heap 5 PSYoungGen total 2752512K, used 15729K [0x0000000700000000, 0x00000007c0000000, 0x00000007c0000000) 6 eden space 2359296K, 0% used [0x0000000700000000,0x0000000700f5c400,0x0000000790000000) 7 from space 393216K, 0% used [0x0000000790000000,0x0000000790000000,0x00000007a8000000) 8 to space 393216K, 0% used [0x00000007a8000000,0x00000007a8000000,0x00000007c0000000) 9 ParOldGen total 6144K, used 965K [0x0000000640000000, 0x0000000640600000, 0x0000000700000000) 10 object space 6144K, 15% used [0x0000000640000000,0x00000006400f1740,0x0000000640600000) 11 Metaspace used 3786K, capacity 4540K, committed 4864K, reserved 1056768K 12 class space used 420K, capacity 428K, committed 512K, reserved 1048576K
日志分析：沒有使用intern情況下，
執行時間為1515ms，占用內存為16694k;
綜上所述:使用intern情況下，內存相對沒有使用intern的情況要小，但在節省內存的同時，增加了時間復雜度。我試過將MAX=10000000再增加一個0的情況下，使用intern將會花費高達11秒的執行時間，可見，在遍歷數據過大時，不建議使用intern。
因此，使用intern的前提，一定要考慮到具體的使用場景。
到這里，可以確定，
使用String.intern確實可以節省內存。
接下來，分析一下intern在不同JDK版本的區別。
在JDK1.6中，字符串常量池在方法區中，方法區屬於永久代。
在JDK1.7中，字符串常量池移到了堆中。
在JDK1.8中，字符串常量池移到了元空間里，與堆相獨立。
分別在1.6、1.7、1.8版本執行以下一個例子：
1 public class test5 { 2 public static void main(String[] args) { 3 4 String s1=new String("ab"); 5 s.intern(); 6 String s2="ab"; 7 System.out.println(s1==s2); 8 9 10 String s3=new String("ab")+new String("cd"); 11 s3.intern(); 12 String s4="abcd"; 13 System.out.println(s4==s3); 14 } 15 }
1.6版本
執行結果：
fasle false
分析：
執行第一部分時：
1.代碼編譯時，先在字符串常量池里創建常量“ab"；在調用new時，將在堆中創建一個String對象，字符串常量創建的“ab"存儲到堆中，最后堆中的String對象返回一個引用給s1。
2.s.intern()，在字符串常量池里已經存在“ab”,便不再創建存放副本“ab"；
3.s2="ab"，s2指向的是字符串常量池里”ab"，而s1指向的堆中的”ab"，故兩者不相等。
該示意圖如下：
執行第二部分：
1.兩個new出來相加的“abcd”存放在堆中，s3指向堆中的“abcd";
2.執行s3.intern()，在將“abcd"副本的存放到字符串常量池時，發現常量池里沒有該”abcd"，因此，成功存放；
3.s4="abcd"指向的是字符串常量池里已有的“abcd"副本，而s3指向的是堆中的"abcd"，副本"abcd"的地址和堆中“abcd"地址不相同，故為false;
1.7版本
false true
執行第一部分：這一部分與jdk1.6基本類似，不同在於，s1.intern()返回的是引用，而不是副本。
執行第二部分：
1.new String("ab")+new String("cd")，先在常量池里生成“ab"和”cd"，再在堆中生成“abcd";
2.執行s3.intern()時，會把“abcd”的對象引用放到字符串常量池里，發現常量池里還沒有該引用，故可成功放入。當String s4="abcd"，即把字符串常量池中”abcd“的引用地址賦值給s4，相當於s4指向了堆中”abcd"的地址，故s3==s4為true。
1.8版本
false true
參考網上一些博客，在1.8版本當中，使用intern()時，執行原理如下：
若字符串常量池中，包含了與當前對象相當的字符串，將返回常量池里的字符串；若不存在，則將該字符串存放進常量池里，並返回字符串的引用。
綜上所述，可見三種版本當中，使用intern時，若字符串常量池里不存在相應字符串時，存在以下區別：
例如：
String s1=new String("ab"); s.intern();
jdk1.6:若字符串常量池里沒有“ab"，則會在常量池里存放一個“ab"副本，該副本地址與堆中的”ab"地址不相等；
jdk1.7:若字符串常量池里沒有“ab"，會將“ab”的對象引用放到字符串常量池里，該引用地址與堆中”ab"的地址相同；
jdk1.8:若字符串常量池中包含與當前對象相當的字符串，將返回常量池里的字符串；若不存在，則將該字符串存放進常量池里，並返回字符串的引用。
3.如何使用字符串的分割方法？
在簡單進行字符串分割時，可以用indexOf替代split，因為split的性能不夠穩定，故針對簡單的字符串分割，可優先使用indexOf代替；