一个简单的例子
反编译结果
javap -verbose命令可以输出更多提示信息，但这里使用的是javap -c，输出的只是一些字节码信息，不过还是强烈建议使用verbose参数。
ldc指令是将运行时常量池的一个常量加载到操作数栈。
解释：
对象之间直接通过 == 来比较，是比较的对象的引用，即是否指向相同的内存空间，所以在strC和strD比较的是引用地址，由于这两个String类型都是通过new关键字来创建的，对于显示使用new关键字创建的字符串都是在堆上分配内存空间，而不会放常量池里。
对于strA与strB：使用文本字符串初始化，在编译期间就被确定，并被编译到class文件中。这些字面量在所在类被类加载器加载时就会将这些常量加载到运行时常量池中。这种在编译期间确定，运行时加载到常量池的变量称为字面量，字面量和Java语言本身的常量(final)概念比较像，如文本字符串和定义为final的基本类型数据等。
还应该注意的是常量池的实现是基于HashMap原理的，当常量池的常量过多时，查找将耗费较多时间。String的equal方法比较的字符串的内容，当内容一致时将返回true。
执行main方法将会创建方法栈，方法内创建的数据是局部变量，存放在方法的局部变量表中，当执行方法的运算语句时会将涉及到的局部变量表中的操作数加载到操作数栈栈中用来进行运算，方法内创建的对象虽然在堆上分配空间，但是此对象的引用保存到局部变量表中，随着方法的执行将对象引用压栈出栈，如果创建final的基本数据类型或者用文本字符串初始化一个String，则会将他们在常量池中的引用保存到局部变量表中，在运行方法时压入操作数栈顶。对于非final的局部基本变量，局部变量表保存的是其数值。
还有方法栈的数据存取速度高于堆的访问，但是空间较小默认为1M，局部变量生存周期为创建开始到方法的结束，并不需要GC，但是在方法内创建的堆上的对象则需要GC来回收。
上述代码的流程：编译的时候，查看常量池中是否含有字符串常量“zhanglbjames”，发现没有，则在这个字符串保存到常量池中，并返回此字符串在常量池中的引用给strA；当初始化strB是还是先去常量池是否含有这个字符常量，发现存在，则返回这个常量的引用给strB，所以使用 == 来判断将返回true。当创建strC和strD时是分别在堆上创建并不会管常量池中是否存在，所以 == 返回false
字符串拼接
为什么在大量字符串拼接的时候要使用StringBuffer和StringBuilder而不使用String.concat方法或者 + ？
- String是不可变对象，使用concat方法并不会按照你想象的那样在原字符串基础上拼接，而是在每一次调用concat方法时都回在内部创建一个char类型的数组，并拷贝原字符串到这个字符数组当中，然后再把待拼接的字符串赋值到字符数组当中，最后在创建一个新的String对象返回，源码如下：
每调用一次concat方法都将进行两次数组复制和创建一个String对象，效率极低。
- 使用 + 号拼接
每一次使用加号拼接字符串都将创建一个StringBuilder对象，然后调用append方法实现拼接的功能。所以效率也不高。但是除了一种情况：
在同一条初始化语句中连续使用 + 来拼接字符串，这是并不会去创建StringBuilder进行拼接，而是将这几个字符串拼接为 “zhangLeBronJames”存放在常量池中。
字面量和String对象用 + 拼接会发生什么？
- 会创建StringBuilder，并调用append方法拼接，然后调用StringBuilder.toString方法在堆上创建一个String对象，并将String对象的引用返回。
- 当对final 修饰的String对象进行拼接时，会直接将字面量拼接并存放在常量池中并返回常量的引用给拼接后的对象。
StringBuffer和StringBuilder的相同点
- 实现原理一样，底层都是基于char类型的数组来保存字符串并实现拼接。
- 方法接口使用上一样。主要有append、toString等。
- 性能缺陷都是由于char类型数组容量有限，扩容时需要进行数组复制，所以可以在创建时指定可能的字符串长度的上限为容量来避免频繁扩容。
StringBuffer和StringBuilder的不相同点
StringBuffer的所有方法都是同步方法，所以是线程安全的。
StringBuilder不是线程安全的。
String. intern()方法详解
在String对象上调用此方法，如果常量池中含有此字符串字面量，则返回其在常量池中的引用，如果常量池中不存则将其放进常量池中，并返回其引用。
此方法本身并没有什么难以理解的地方，但是要注意在不同版本JDK中JVM中常量池所在的内存区域
1.6及之前 常量池在方法区内，方法区有容量限制，当常量池里元素太多时，将触发永久代的GC，而永久代的GC和老年代GC绑定在一起（无论谁满都将触发永久代和老年代的GC），所以在jdk1.6及之前中，频繁调用intern方法将降低系统性能，频繁发生GC。
1.7(某个版本之后，具体忘了) 常量池被移动到java堆上分配（方法区还存在），所以常量池的大小受限于堆的大小，所以频繁调用intern方法，在某种情况下可以提高效率。
1.8 常量池被移动到java堆上分配（完全移除方法区和永久代，取而代之的是元数据），所以常量池的大小受限于堆的大小，所以频繁调用intern方法，在某种情况下可以提高效率。
什么场景频繁调用intern可以提高效率？
当一个字符串重复出现的次数达到极高的频率，比如10000次及以上，而且不重复出现的字符串数量很少比如100-500。
