字符串问题可谓是 Java 中经久不衰的问题，尤其是字符串常量池经常作为面试题出现。可即便是看似简单而又经常被提起的问题，还是有好多同学一知半解，看上去懂了，仔细分析起来却又发现不太明白。
背景说明
本文以 JDK 1.8 为讨论版本，虽然现在都已经 JDK 14了，奈何我们还是钟爱 1.8。
一个提问引起的讨论
为什么说到字符串常量呢，源于群里为数不多的一个程序员小姐姐的提问。
为什么会有"Java开发_北京"这么奇特的字符串乱入呢，因为提出问题的这位小姐姐的群昵称叫这个，所以群里的同学开玩笑说，以为她是某个房地产大佬，要来开发北京。 
以上是开个玩笑，好了，收。
字符串用 == 比较也是 true，这就有意思了。马上有机灵的小伙伴说这和字符串常量池有关系。没错，就是因为字符串常量池的原因。
第一张图其实没什么好说的，在 JDK 1.8 之后已经不允许 Object 和 int 类型用 == 相比较了，编译直接报错。
第二张图中的代码才是重点要说的，我们可以把它简化成下面这段代码，用 == 符号比较字符串，之后的内容都从这几行代码出发。
public static void main(String[] args) {
String s1 = "古时的风筝";
System.out.println(s1 == "古时的风筝");
} 当然，实际开发中强烈不推荐用 == 符号判断两个字符串是否相等，应该用 equals() 方法。
字符串常量池何许人也
为什么要有字符串常量池呢，像其他对象一样直接存在堆中不行吗，这就要问 Java 语言的设计者了，当然，这么做也并不是拍脑袋想出来的。
这就要从字符串说起。
首先对象的分配要付出时间和空间上的开销，字符串可以说是和 8 个基本类型一样常用的类型，甚至比 8 个基本类型更加常用，故而频繁的创建字符串对象，对性能的影响是非常大的，所以，用常量池的方式可以很大程度上降低对象创建、分配的次数，从而提升性能。
在 JDK 1.7 之后(包括1.7)，字符串常量池已经从方法区移到了堆中。
字面量赋值
我们把上面的那个实例代码拿过来
String s1 = "古时的风筝"; 这是我们平时声明字符串变量的最常用的方式，这种方式叫做字面量声明，也就用把字符串用双引号引起来，然后赋值给一个变量。
这种情况下会直接将字符串放到字符串常量池中，然后返回给变量。
那这是我再声明一个内容相同的字符串，会发现字符串常量池中已经存在了，那直接指向常量池中的地址即可。
例如上图所示，声明了 s1 和 s2，到最后都是指向同一个常量池的地址，所以 s1== s2 的结果是 true。
new String() 方式
与之对应的是用 new String() 的方式，但是基本上不建议这么用，除非有特殊的逻辑需要。
String a = "古时的";
String s2 = new String(a + "风筝"); 使用这种方式声明字符串变量的时候，会有两种情况发生。
第一种情况，字符串常量池之前已经存在相同字符串
比如在使用 new 之前，已经用字面量声明的方式声明了一个变量，此时字符串常量池中已经存在了相同内容的字符串常量。
- 首先会在堆中创建一个 s2 变量的对象引用；
- 然后将这个对象引用指向字符串常量池中的已经存在的常量；
第二种情况，字符串常量池中不存在相同内容的常量
之前没有任何地方用到了这个字符串，第一次声明这个字符串就用的是 new String() 的方式，这种情况下会直接在堆中创建一个字符串对象然后返回给变量。
我看到好多地方说，如果字符串常量池中不存在的话，就先把字符串先放进去，然后再引用字符串常量池的这个常量对象，这种说法是有问题的，只是 new String() 的话，如果池中没有也不会放一份进去。
基于 new String() 的这种特性，我们可以得出一个结论：
String s1 = "古时的风筝";
String a = "古时的";
String s2 = new String(a + "风筝");
String s3 = new String(a + "风筝");
System.out.println(s1==s2); // false
System.out.println(s2==s3); // false 以上代码，肯定输出的都是 false，因为 new String() 不管你常量池中有没有，我都会在堆中新建一个对象，新建出来的对象，当然不会和其他对象相等。
intern() 池化
那什么时候会放到字符串常量池呢，就是在使用 intern() 方法之后。
intern() 的定义：如果当前字符串内容存在于字符串常量池，存在的条件是使用 equas() 方法为ture，也就是内容是一样的，那直接返回此字符串在常量池的引用；如果之前不在字符串常量池中，那么在常量池创建一个引用并且指向堆中已存在的字符串，然后返回常量池中的地址。
第一种情况，准备池化的字符串与字符串常量池中的字符串有相同(equas()判断)
String s1 = "古时的风筝";
String a = "古时的";
String s2 = new String(a + "风筝");
s2 = s2.intern(); 这时，这个字符串常量已经在常量池存在了，这时，再 new 了一个新的对象 s2，并在堆中创建了一个相同字符串内容的对象。
这时，s1 == s2 会返回 fasle。然后我们调用 s2 = s2.intern()，将池化操作返回的结果赋值给 s2，就会发生如下的变化。
此时，再次判断 s1 == s2 ，就会返回 true，因为它们都指向了字符串常量池的同一个字符串。
第二种情况，字符串常量池中不存在相同内容的字符串
使用 new String() 在堆中创建了一个字符串对象
使用了 intern() 之后发生了什么呢，在常量池新增了一个对象，但是 并没有 将字符串复制一份到常量池，而是直接指向了之前已经存在于堆中的字符串对象。因为在 JDK 1.7 之后，字符串常量池不一定就是存字符串对象的，还有可能存储的是一个指向堆中地址的引用，现在说的就是这种情况，注意了，下图是只调用了 s2.intern()，并没有返回给一个变量。其中字符串常量池（0x88）指向堆中字符串对象（0x99）就是intern() 的过程。
只有当我们把 s2.intern() 的结果返回给 s2 时，s2 才真正的指向字符串常量池。
我明白了
通过以上的介绍，我们来看下面的一段代码返回的结果是什么
public class Test {
public static void main(String[] args) {
String s1 = "古时的风筝";
String s2 = "古时的风筝";
String a = "古时的";
String s3 = new String(a + "风筝");
String s4 = new String(a + "风筝");
System.out.println(s1 == s2); // 【1】 true
System.out.println(s2 == s3); // 【2】 false
System.out.println(s3 == s4); // 【3】 false
s3.intern();
System.out.println(s2 == s3); // 【4】 false
s3 = s3.intern();
System.out.println(s2 == s3); // 【5】 true
s4 = s4.intern();
System.out.println(s3 == s4); // 【6】 true
}
} 【1】：s1 == s2 返回 ture，因为都是字面量声明，全都指向字符串常量池中同一字符串。
【2】: s2 == s3 返回 false，因为 new String() 是在堆中新建对象，所以和常量池的常量不相同。
【3】: s3 == s4 返回 false，都是在堆中新建对象，所以是两个对象，肯定不相同。
【4】: s2 == s3 返回 false，前面虽然调用了 intern() ，但是没有返回，不起作用。
【5】: s2 == s3 返回 ture，前面调用了 intern() ，并且返回给了 s3 ，此时 s2、s3 都直接指向常量池的同一个字符串。
【6】: s3 == s4 返回 true，和 s3 相同，都指向了常量池同一个字符串。
为啥我字符串就不可变
字符串常量池的基础就是字符串的不可变性，如果字符串是可变的，那想一想，常量池就没必要存在了。假设多个变量都指向字符串常量池的同一个字符串，然后呢，突然来了一行代码，不管三七二十一，直接把字符串给变了，那岂不是 jvm 世界大乱。
字符串不可变的根本原因应该是处于安全性考虑。
我们知道 jvm 类型加载的时候会用到类名，比如加载 java.lang.String 类型，如果字符串可变的话，那我替换成其他的字符，那岂不是很危险。
项目中会用到比如数据库连接串、账号、密码等字符串，只有不可变的连接串、用户名和密码才能保证安全性。
字符串在 Java 中的使用频率可谓高之又高，那在高并发的情况下不可变性也使得对字符串的读写操作不用考虑多线程竞争的情况。
还有就是 HashCode，HashCode 是判断两个对象是否完全相等的核心条件，另外，像 Set、Map 结构中的 key 值也需要用到 HashCode 来保证唯一性和一致性，因此不可变的 HashCode 才是安全可靠的。
最后一点就是上面提到的，字符串对象的频繁创建会带来性能上的开销，所以，利用不可变性才有了字符串常量池，使得性能得以保障。