关于String你还需要知道这些细节

关于String + 的故事

只要是写Java的，String肯定是经常用的，比如下面这样的代码(可能我们都写烂了)

String a = "Hello";
String b = "java";
String ab = a + b;

我们也一直都是这样写的，但是如果我们再进一步想一下就会发现问题，String在java中是一个类，java中是没有运算符重载的，那么二个String为什么可以直接用 + 号进行拼接呢？为了一探究竟，我们还是要看编译后的字节码。

L0
  LINENUMBER 18 L0
  LDC "Hello"
  ASTORE 1
L1
  LINENUMBER 19 L1
  LDC "java"
  ASTORE 2
L2
  LINENUMBER 20 L2
  NEW java/lang/StringBuilder
  DUP
  INVOKESPECIAL java/lang/StringBuilder.<init> ()V
  ALOAD 1
  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
  ALOAD 2
  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
  INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
  ASTORE 3

可以看到编译器new了一个 StringBuilder对象，然后调用了2次append方法进行字符串的拼接。也就是说+号拼接String 只是Java语言的语法糖而已，就跟上一篇说的自动装箱和拆箱一个意思。

测试一下编译器的智商

既然编译器会帮我们将String + 号拼接转化为StringBuilder拼接，那我们就用一段代码来测试一下它的智商到底怎么样。

String result = "";
for (int i = 0; i < 10; i++) {
   String a = "Hello";
   result += a;
}

同样很简单，我们来看字节码

L0
  LINENUMBER 18 L0
  LDC ""
  ASTORE 1
L1
  LINENUMBER 19 L1
  ICONST_0
  ISTORE 2
L2
  FRAME APPEND [java/lang/String I]
  ILOAD 2
  BIPUSH 10
  IF_ICMPGE L3
L4
  LINENUMBER 20 L4
  LDC "Hello"
  ASTORE 3
L5
  LINENUMBER 21 L5
  NEW java/lang/StringBuilder
  DUP
  INVOKESPECIAL java/lang/StringBuilder.<init> ()V
  ALOAD 1
  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
  ALOAD 3
  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
  INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
  ASTORE 1
L6
  LINENUMBER 19 L6
  IINC 2 1
  GOTO L2

可以看到StringBuilder的创建是在循环体内创建的，所以会多次创建多个对象，效率很低，所以编译器没有那么智能，了解了这个，以后项目中需要循环拼接字符串时，避免直接使用+拼接。

字符串 + 还另有玄机

直接看下面的代码

final String a = "hello";
final String b = "world";
String result = a + b;

没看出来什么特别的！！！到底玄机在哪，直接看字节码

L0
  LINENUMBER 19 L0
  LDC "hello"
  ASTORE 1
L1
  LINENUMBER 20 L1
  LDC "world"
  ASTORE 2
L2
  LINENUMBER 21 L2
  LDC "helloworld"
  ASTORE 3

额，编译器直接帮我们把a+b拼接了，因为a和b都是final类型的，在编译期值也是确定的，所以编译器帮我们做了这个优化。这一块的知识，就不展开的特别多的去分析了，目前我们得到的结论就是如果字符串拼接的双方都是 final 类型的常量字符串，编译器就会帮我们直接进行优化。

字符串常量池的故事

Java的设计者为了提高Java的运行效率，有很多精心的设计，字符串常量池就是其中之一（String Constant Pool）,我们后面都简称为SCP。还是先看一段代码（面试题中经常见）

final String a = "hello";
final String b = "hello";
final String c = new String("hello");
final String d = c.intern();

System.out.println("a==b:" + (a == b));
System.out.println("a==c:" + (a == c));
System.out.println("a==d:" + (a == d));

运行结果如下：

a==b:true (a和b都存在于SCP中，所以它们是一个对象)
a==c:false （new的对象存在于堆中，所以c和a不是一个对象）
a==d:true （intern方法将字符串放入SCP中，并返回，所以a和d是一个对象）

SCP确实可以一定程度减少对象的重复创建，但是我们再想一种情形，如果我们改变了a字符串的值，我们肯定不希望b跟着变，但是a和b又指向同一个对象，很可能a 的修改会产生我们不愿意看到的结果。其实是没有问题的，因为Java中String是被设计成不可变的，如果要变就会重新生成一个新的对象，不会影响旧的对象，这也是SCP能够正常工作的前提。

SCP的前世今生

SCP在JDK6 之前是被设计在永久代中的，并且不会进行垃圾回收，默认大小64M（可以通过-XX:MaxPermSize进行设置），所以如果在循环中，不断创建常量字符串放入SCP中，会导致OOM。JDK7开始，SCP被设计在堆中，这样它的大小限制被大大的放开了，而且会进行垃圾回收，Java也在不断的优化进步😆。

最后：我自己的一点点小思考

为什么Java的设计者将String要被设计成immutable???
我想可能有以下2个原因

为了SCP的优化
线程安全

设计没有完美的，有得必有失，immutable导致String的扩展被限制，所以Java提供了StringBuilder和StringBuffer二个类来帮助我们进行字符串操作。

以上