java中特殊的String类型(深入)

一、先讲一下java 虚拟机内存分布

1、程序计数器（Program Counter Register）

程序计数器是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。

由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，所以在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）都只会执行一条线程中的指令。因此，为了线程切换后能够恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器。

各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“ 线程私有 ”的内存。

熟悉C++的读者应该了解“现场保护”这个概念，虽然“现场保护”对应的是函数调用，而这里的程序计数器对应的是线程之间的切换，但笔者认为它们的作用非常相似：都是为了线程或函数执行完后能够恢复到正确的位置。

2、Java虚拟机栈（Java Virtual Machine Stacks）

我们平时所说的栈区就是Java虚拟机栈。

与程序计数器一样，Java虚拟机栈也是线程私有的，生命周期与线程相同。

虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈桢（Stack Frame）用于存储该方法的信息，如局部变量表、操作数栈、方法的出口等信息。

每个方法从调用直至执行完成的过程，就对应着一个栈桢入栈到出栈的过程。

局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，不是对象本身）和returnAddress类型（指向了一条字节码指令的位置）。

Java虚拟机规范中，对这个区域规定了两种异常状况：StackOverflowError异常和OutOfMemoryError异常。

3、Java堆（Java Heap）

Java堆是Java虚拟机所管理的内存中最大的一块，该内存是被所有线程共享的，在虚拟机启动时创建。此内存区域存在的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。既然Java堆中存放了几乎所有的实例，那么这里自然就成了垃圾收集器管理的主要区域。

当对中没有内存完成了实例分配，并且堆也无法再扩张时，将会抛出OutOfMemoryError异常。

4、方法区（Method Area）

方法区与Java堆一样，是各个线程共享的内存区域。

它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

方法区还包括了运行时常量池。

当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

5、本地方法栈（Native Method Stack）

本地方法栈与虚拟机栈的作用非常相似，它们的区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为了虚拟机使用到的Native方法服务。

在虚拟机规范中队本地方法栈方法使用的语言、使用的法师与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（如 Sun HotSpot 虚拟机）直接就把本地方法栈和虚拟机栈合二为一。

该数据区抛出的异常和虚拟机栈相同：都会抛出StackOverflowError和OutOfMemoryError异常。

6、运行时常量池（Runtime Constant Pool）

运行时常量池属于方法区的一部分。虽然Java虚拟机没有单独为运行时常量池划分内存空间，但是由于该区域在平时开发中也是一个重要的部分，所以也为它单独列一个条目。

Class文件中除了有类的版本、字段、方法、接口的描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量的引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

运行时常量池相对于Class文件常量池的另外一个重要特征是具有动态性，Java语言并不要求常量一定只有编译期才能产生，也就是说并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，如String类的intern()方法。

既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存是会抛出OutOfMemoryError异常。

二、Java中String类型的创建方式

两种创建形式：

1. String s = “abc”;

2. String s = new String(“abc”);

第一种先在栈中创建一个对String类的对象引用变量s，然后去查找”abc”是否被保存在字符串常量池中，如果没有则在栈中创建三个char型的值’a’、’b’、’c’，然后在堆中创建一个String对象object，它的值是刚才在栈中创建的三个char型值组成的数组{‘a’、’b’、’c’}，接着这个String对象object被存放进字符串常量池，最后将s指向这个对象的地址，如果”abc”已经被保存在字符串常量池中，则在字符串常量池中找到值为”abc”的对象object，然后将s指向这个对象的地址。

第一种特点：JVM会自动根据栈中数据的实际情况来决定是否有必要创建新对象。

第二种可以分解成两步1、String object = "abc"; 2、String s = new String(object); 第一步参考第一种创建方式，而第二步由于"abc"已经被创建并保存到字符串常量池中，因此jvm只会在堆中新创建一个String对象，它的值共享栈中已有的三个char型值。

第二种特点：一概在堆中创建新对象，而不管其字符串值是否相等，是否有必要创建新对象。

在讲字符串比较前，必须要了解==和equals的区别：

因为java所有类都继承于Object基类，而Object中equals用==来实现，所以equals和==是一样的，都是比较对象地址，java api里的类大部分都重写了equals方法，包括基本数据类型的封装类、String类等。对于String类==用于比较两个String对象的地址，equals则用于比较两个String对象的内容(值)。

例1：字符串常量池的使用

String s0 = "abc";
String s1 = "abc";
System.out.println(s0==s1); //true  可以看出s0和s1是指向同一个对象的。

例2：String中==与equals的区别

String s0 =new String ("abc");
String s1 =new String ("abc");
System.out.println(s0==s1); //false 可以看出用new的方式是生成不同的对象
System.out.println(s0.equals(s1)); //true 可以看出equals比较的是两个String对象的内容(值)

例3：编译期确定　

String s0="helloworld";
String s1="helloworld";
String s2="hello" + "word";
System.out.println( s0==s1 ); //true 可以看出s0跟s1是同一个对象
System.out.println( s0==s2 ); //true 可以看出s0跟s2是同一个对象

分析：因为例子中的 s0和s1中的”helloworld”都是字符串常量，它们在编译期就被确定了，所以s0==s1为true；而”hello”和”world”也都是字符串常量，当一个字符串由多个字符串常量连接而成时，它自己肯定也是字符串常量，所以s2也同样在编译期就被解析为一个字符串常量，所以s2也是常量池中”helloworld”的一个引用。所以我们得出s0==s1==s2；

例4：编译期无法确定

String s0="helloworld";
String s1=new String("helloworld");
String s2="hello" + new String("world");
System.out.println( s0==s1 ); //false
System.out.println( s0==s2 ); //false
System.out.println( s1==s2 ); //false

分析：用new String() 创建的字符串不是常量，不能在编译期就确定，所以new String() 创建的字符串不放入常量池中，它们有自己的地址空间。

s0还是常量池中”helloworld”的引用，s1因为无法在编译期确定，所以是运行时创建的新对象”helloworld”的引用，s2因为有后半部分new String(”world”)所以也无法在编译期确定，所以也是一个新创建对象”helloworld”的引用；

例5：编译期优化

String s0 = "a1";
String s1 = "a" + 1;
System.out.println((s0 == s1)); //result = true
String s2 = "atrue";
String s3= "a" + "true";
System.out.println((s2 == s3)); //result = true
String s4 = "a3.4";
String s5 = "a" + 3.4;
System.out.println((a == b)); //result = true

分析：在程序编译期，JVM就将常量字符串的”+”连接优化为连接后的值，拿”a” + 1来说，经编译器优化后在class中就已经是a1。在编译期其字符串常量的值就确定下来，故上面程序最终的结果都为true。

例6：编译期无法确定

String s0 = "ab";
String s1 = "b";
String s2 = "a" + s1;
System.out.println((s0 == s2)); //result = false

分析：JVM对于字符串引用，由于在字符串的”+”连接中，有字符串引用存在，而引用的值在程序编译期是无法确定的，即”a” + s1无法被编译器优化，只有在程序运行期来动态分配并将连接后的新地址赋给s2。所以上面程序的结果也就为false。

例7：编译期确定

String s0 = "ab";
final String s1 = "b";
String s2 = "a" + s1;
System.out.println((s0 == s2)); //result = true

分析：和[6]中唯一不同的是s1字符串加了final修饰，对于final修饰的变量，它在编译时被解析为常量值的一个本地拷贝存储到自己的常量 池中或嵌入到它的字节码流中。所以此时的”a” + s1和”a” + “b”效果是一样的。故上面程序的结果为true。

例8：编译期无法确定

String s0 = "ab";
final String s1 = getS1();
String s2 = "a" + s1;
System.out.println((s0 == s2)); //result = false
private static String getS1() {  return "b";   }

分析：JVM对于字符串引用s1，它的值在编译期无法确定，只有在程序运行期调用方法后，将方法的返回值和”a”来动态连接并分配地址为s2，故上面 程序的结果为false。

关于String的不可变设计:

String是不可改变类(记:基本类型的包装类都是不可改变的)的典型代表，也是Immutable设计模式的典型应用，String变量一旦初始化后就不能更改，禁止改变对象的状态，从而增加共享对象的坚固性、减少对象访问的错误，同时还避免了在多线程共享时进行同步的需要。

Immutable模式的实现主要有以下两个要点：

1．除了构造函数之外，不应该有其它任何函数（至少是任何public函数）修改任何成员变量。

2．任何使成员变量获得新值的函数都应该将新的值保存在新的对象中，而保持原来的对象不被修改。

String的不可变性导致字符串变量使用+号的代价：

例9：

String s = "a" + "b" + "c";
String s1  =  "a";
String s2  =  "b";
String s3  =  "c";
String s4  =   s1  +  s2  +  s3;

分析：变量s的创建等价于 String s = “abc”; 由上面例子可知编译器进行了优化，这里只创建了一个对象。由上面的例子也可以知道s4不能在编译期进行优化，其对象创建相当于：

StringBuffer temp = new StringBuffer();

temp.append(s1).append(s2).append(s3);

String s = temp.toString();

由上面的分析结果，可就不难推断出String 采用连接运算符（+）效率低下原因分析，形如这样的代码：

public class Test {
public static void main(String args[]) {
String s = null;
for(int i = 0; i < 100; i++) {
s += "a";
}
}
}

　每做一次 + 就产生个StringBuffer对象，然后append后就扔掉。下次循环再到达时重新产生个StringBuffer对象，然后append 字符串，如此循环直至结束。如果我们直接采用StringBuffer对象进行append的话，我们可以节省N - 1次创建和销毁对象的时间。所以对于在循环中要进行字符串连接的应用，一般都是用StringBuffer或StringBulider对象来进行append操作。