Java中的String
Java.Lang.String是Java语言自带的字符串实现，它并不是java的基本类型，但却和几乎每个java程序都密切相关的一个基础java类。
string类内部实际实现存储的字符数组在定义时用关键字final修饰，意味着这个属性是一个常量，在初始化之后就不能再被修改。这也同时表明所有对String对象的修改操作（包括append，substring，concat，replace，trim等），在具体实现中返回的都是一个全新的string对象副本。总结来说，Java中的String具有不变性、不可继承性。
讨论String对象在内存中的存储
这里会涉及到三个概念：虚拟机栈、Java堆和运行时常量池，在我的第一篇文章中都有描述。根据JDK源码中的规范，String类的使用方式有如下几种：
String str1 = new String("abc");
String str2 = "abc";
String str3 = "ab" + new String("c");
在具体应用中，这里的几种String对象的创建方式是基本没有区别的。但实质上这里有一些微小的差异：第一个字符串的创建方式str1指向的对象被分配到了Java堆中，且创建的时机是在程序运行时。str2指向的字符串对象在编译期就已经确定，存放在运行时常量池中。str3的创建是一个比较复杂的过程，java虚拟机会重新组织对应的字节码，具体的过程在下文会分析。
在学习的过程中，我也参考了很多前辈的文章，其中包括这篇《Java内存分配和String类型的深度解析》，文中作者在String的定义方法中提出了针对性的几点疑问，结合我自身的思考，我来尝试解答一下。
- 堆中new出来的实例和常量池中的是什么关系？
两者都是一个String类型的实例化对象，即使通过方法equals比较返回结果为true，两者在本质上都不会是同一个对象。
- 常量池中的字符串常量与堆中的String对象有什么区别？
一个最主要的区别就是内存中的位置不同，当然大部分的常量池中的字符串常量是在编译器确定的，除非很明确的调用string对象的intern方法返回（或创建）一个运行时常量池中的string对象，所有通过new操作符创建的string对象都会被分配到Java堆中。
- 为什么直接定义的字符串同样可以调用String对象的各种方法呢？
虽然说字符串常量”abc”是在编译器被确定的字符串常量，被存放在运行时常量池，但是这个常量字符串还是一个String类型的对象（这一点确实有别于c/c++语言中的常量的概念，也看出在java的哲学中万物都是对象），如果是一个标准的java对象，它可以调用String的方法。
字节码分析
在分析问题的过程中，通过查看上文中提到的三行java代码对应的字节码（方法javap -c {具体要查看的*.class文件}），来确认我的自己的猜想，在这个过程中也可以看出java编译器对源代码的处置，具体的字节码分析如下：
//0 ~ 9 对应的是第一行的java语句：String str1 = "abc";
0: new #21 // class java/lang/String
3: dup
/*
**装载一个常量字符串 ，符号#23代表的字符串对象就是 “abc”,
**常量字符串在程序运行之前就已经被创建
*/
4: ldc #23 // String abc
/*str1不指向常量字符串“abc”,
**而是将这个常量字符串作为构造函数的实参传入
**在java堆中重新创建了一个全新的对象
*/
6: invokespecial #25 // Method java/lang/String."<init>":(Ljava/lang/String;)V
9: astore_1
//从这里开始到12 都是第二行的Java代码: String str2 = "abc";
/*
** 直接调用运行时常量池中的对象
*/
10: ldc #23 // String abc
12: astore_2
//从此处开始到最后对应第三行的Java代码:String str3 = "ab" + new String("c");
/*
**对于这种new 对象与 常量字符串相结合的方式，
**JAVA编译器在处理过程中创建了一个StringBuilder对象用于处理异构字符串的拼接工作
** "ab"对应另一个常量字符串 “c”则运行时动态创建的String对象
**/
13: new #28 // class java/lang/StringBuffer
16: dup
17: ldc #30 // String ab
19: invokespecial #32 // Method java/lang/StringBuffer."<init>":(Ljava/lang/String;)V
22: new #21 // class java/lang/String
25: dup
26: ldc #33 // String c
28: invokespecial #25 // Method java/lang/String."<init>":(Ljava/lang/String;)V
31: invokevirtual #35 // Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
34: invokevirtual #39 // Method java/lang/StringBuffer.toString:()Ljava/lang/String;
37: astore_3
38: return
由此可以看出，在处理不同方式构建的字符串拼接时，java编译器为我们付出了额外的一些代价，在我们的代码中，尽可能少出现类似第三行那样的代码。如果是确定的字符串常量，也尽可能写成”ab” + “c”这样的形式，在编译器优化时会在常量池中找到现成的对象对象，会在性能上有很大的提升。
同时我们能够看到编译器默认用的字符串拼接器是StringBuffuer类，通常情况下我们如果需要对几个动态的string对象做拼接用的都是StringBuilder类。StringBuffer与StringBuilder最本质的区别是：前者是线程安全的。那么如果只是明确的单线程环境下，在效率上编译器自补足的代码又会有更多性能上的欠缺。
