关于java String字符串相加的问题

//JAVA字符串的研究
public class JustString {
public static void main(String[] args) {
String s1 = “ZhouJie”;
String s2 = “Zhou”;
String s3 = “Jie”;
String s4 = “Zhou” + “Jie”;
String s5 = s2 + s3;
String s5s = s5.intern();
String s6 = “Zhou” + s3;
String s6s = s6.intern();

String s7 = new String(“ZhouJie”);
String s7s = s7.intern();

System.out.println(s1 == s4);// 1、true
System.out.println(s1 == s5);// 2、false
System.out.println(s1 == s5s);// 3、true
System.out.println(s1 == s6);// 4、false
System.out.println(s1 == s6s);// 5、true
System.out.println(s1 == s7);// 6、false
System.out.println(s1 == s7s);// 7、true

一、1和6的结果很简单，s1是字符直接赋值所以s1在栈中的地址指向的字符串存储在常量池中，而s7是new出来的，new出来的字符串都存储在堆中（而且一定是生成新的字符串，不管堆中有没有值相同的字符串）。s4也是直接赋值相加所以相加的结果回去常量池中寻找一样的字符串，所以s1和s4都是指向常量池中的"ZhouJie"字符串。
二 、2和4放在一起说，因为他们的本质是一样的。
对于2和4，如果用开始的那个等式来套用下，结果应该都是true,但java给出了false，看来不是这个等式有问题就是java对这个
等式的处理有问题。事实是等式没有问题，问题在java对这个等式的处理方式上。
当+号中有变量时(这里的变量指严格意义上的变量，除了直接的字面上的字符，所有需要一次以上处理才能成为直接 字面字符的 值存在时 java都一律将其视为变量)，因为对于s2+s3和"Zhou"+s3,java并不知道这里面到底是什么，从上面的定义看，它只 知 道这个 变量是String类型的(对于运行前的编译来说这些信息足够了),既然是变量，那么java都会放在运行期才会去确定变量 的具 体值。
——PS：这里的解释放在多态里面也是通用的，即：子类的对象引用赋值给父类的引用，编译时只会检查是否具有继承关系，也 就是检查是否 是同一个类型的，至于具体的值不管，运行期间再说，最终的效果就是运行时的多态。

所以有句话很经典：覆盖是运行时的多态。因为子类的行为状态覆盖了父类的行为状态。

接着说字符串，既然都是变量，跟多态的原理一样，java会在运行的时候去处理+号两边的变量。但是具体的方式不一样，对于字 符串的 运算，如果是变量 ，那么java会先new出一个StringBuilder(在JDK6.0之前是StringBuffer),然后调用append()方法
来将+号两遍的字符串拼接起来(底层就是char数组的拼接),然后toString()之后返回给=号左边的变量，也就是说，最后得到的
是一个new出来的字符串，那么这个字符串必然是在堆中了。结果就必然会是false了。
2和4，一个+两遍都是变量，另一个只有一个变量，但对于java来说，只要是变量，它就会去new一个StringBuilder来拼接，对
它来说这没有什么区别。
顺便解释一下s4的运算机制，对于s4的+两边都是字面字符常量来说，java在编译期就将+两边拼接合并了而不会等到运行时再 算，因为在 java看来，这样的运算即使放到运行时也不会有变化，运行期间重点要解决的是变化的东西。

后面又发现一个问题
当这个字符串呗final修饰时的问题
String a = “hello2”;
final String b = “hello”;
String c = b + 2;
System.out.println((a == c));//true
这时的String c = b + 2;相当于String c = “hello” + 2;因为b呗final修饰，不能被改变，是个常量，所以在编译的时候电脑就知道b一定是“hello”，所以会直接使用“hello”。

详细解决请看原文链接。
版权声明：本文为CSDN博主「imzhoujie」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zhongbeizhoujie/article/details/44549749