一、String的基本特性

1.String字符串，使用一对""引起来表示。

2.String声明为final的，不可被继承。

3.String实现了Serializable接口，表示字符串是支持序列化的。实现了Comparable接口，表示String可以比较大小。

4.String在jdk8及以前内部定义了final char[] value用于存储字符串数据。jdk9时改为byte[]。

5.String代表不可变的字符序列。简称：不可变性。

（1）当字符串重新赋值时，需要重写指定内存区域赋值，不能使用原有的value进行赋值。

（2）当对现有的字符串进行连接操作时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值。

（3）当调用String的replace()方法修改指定字符或字符串时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值。

6.通过字面量的方式（区别于new，String a = ‘abc’;）给一个字符串赋值，此时字符串值声明在字符串常量池中。

7.字符串常量池中是不会存储相同内容的字符串的。

8.String的String Pool是一个固定大小的HashTable，默认值大小长度是1009.如果放进String Pool的String非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了后直接会造成的影响就是当调用String.intern时性能会大幅下降。

9.使用-XX:StringTableSize可以设置StringTable的长度。

10.在jdk6中StringTable是固定的，就是1009的长度，所以如果常量池中的字符串过多就会导致效率下降很快。StringTableSize设置没有要求。

11.在jdk7中，StringTable的长度默认值是60013，StringTable的设置没有要求。

12.jdk8中，StringTable的长度默认值是60013，1009是可设置的最小值。

为什么jdk9String由char[]改为了byte[]去存？

主要还是节省空间。

JDK9 之前的库的 String 类的实现使用了 char 数组来存放字符串，char 占用16位，即两字节。

研究发现String是堆空间的主要部分，同时大部分String都是一些拉丁文，一个字节就能够撑得下，如果使用char的话，因为char占两个字节，所以有一半的空间被浪费掉。

所以，由char[]改为了byte[]，再补一个字符标码集的标识coder；如果是ISO-8859-1、Latin-1就用一个byte去存，如果是UTF-16还是用两个字节去存。

结论：String再也不用char[]来存储了，改成了byte[]加上编码标记，节约了一些空间。

String存储结构发生了变更，StringBuffer和StringBuilder是否改变了？

基于String的类，比如StringBuilder、StringBuffer以及HotSpot虚拟机内部的一些类也进行了修改。

实例（因为String不可变性，原来地址的值是无法被改变的）：

二、String的内存分配

1.在Java语言中有8种基本数据类型和一种比较特殊的类型String。这些类型为了使它们在运行过程中速度更快、更节省内存，都提供了一种常量池的概念。

2.常量池就类似一个Java系统级别提供的缓存。8种基本数据类型的常量池都是系统协调的，String类型的常量池比较特殊。它的主要使用方法有两种。

（1）直接使用双引号声明出来的String对象会直接存储在常量池中。（String a = “aaa”;）

（2）如果不是用双引号声明的String对象，可以使用String提供的intern()方法。

3.Java 6及以前，字符串常量池存放在永久代。

4.Java7中Oracle的工程师对字符串池的逻辑做了很大的改变，即将字符串常量池的位置调整到Java堆内。

所有的字符串都保存在堆（Heap）中，和其他普通对象一样，这样可以让你在进行调优应用时仅需要调整堆大小就可以了。

字符串常量池概念原本使用得比较多，但是这个改动使得我们又足够的理由让我们重新考虑在java7中使用String.intern()。

5.java8永久代变为元空间，字符串常量还是在堆。

为什么要将StringTable进行调整，从永久代->堆？

1.永久代空间有限，将字符串放在永久代容易报OOM-永久代内存溢出。

2.永久代回收频率很低。

三、String的基本操作

java语言规范里要求完全相同的字符串字面量，应该包含同样的Unicode字符序列（包含同一份码点序列的常量），并且必须是指向同一个String类实例。

实例1：

debug下，可以逐行查看字符串常量池，首次加载1-10之后，再次打印就不会再往字符串常量池里加1-10字符串了：

实例2：

line3、line4的new的Object()、Memory()都是指向堆空间。

line6的param也指向堆空间Object()。

line7的param的toString()方法返回一个字符串，字符串存在字符串常量池里。

四、字符串拼接操作

1.常量与常量的拼接结果在常量池，原理是编译期优化。

2.常量池中不会存在相同内容的常量。

3.只要其中有一个是变量，结果就在堆中。变量拼接的原理是StringBuilder。

4.如果拼接的结果调用intern()方法，则主动将常量池中还没有的字符串对象放入池中，并返回此对象地址。

实例1：（常量与常量的拼接结果在常量池）

反编译结果：

实例2：（拼接其中有一个是变量，结果就在堆中，相当于新new的String）

intern()方法就是判断字符串常量池中是否存在这个字符串，如果存在则返回常量池中字符串地址，如果不存在就在常量池中加载字符串并返回此地址。

实例3：（字符串变量拼接底层是用StringBuilder）

根据字节码指令可以看出，拼接字符串变量，先new了StringBuilder，然后使用append操作，然后调用toString()方法。

StringBuilder的toString()方法，约等于new String(“”)。具体继续往下看。

（补充：jdk1.5之后，拼接字符串使用StringBuilder，jdk1.5之前使用StringBuffer）

实例4：

字符串拼接操作，不一定是用的StringBuilder。如果拼接符号左右两边都是字符串常量或者常量引用（final修饰），则仍然使用编译期优化，非StringBuilder方式。

所以，针对于final修饰的类、方法、基本数据类型、引用数据类型的结构时，能使用上final的时候建议使用上。

反编译：

实例5：练习

实例6：多个字符串拼接，其实也只new了一个StringBuilder

实例7：for循环中拼接字符串

可以看出，for每循环一次就会new一个StringBuilder。所以，拼接字符串最好还是直接使用StringBuilder，而不是“+”。

总结：

字符串拼接最好使用StringBuilder调用append来拼接。

使用加号“+”拼接，会new一个StringBuilder，并且在最后调用toString方法时还会new String()。

内存中由于创建了较多的StringBuilder和String对象，还有一方面是内存占用，调用GC还会额外花费时间。

所以，字符串拼接直接使用StringBuilder会大大提高性能，尤其是多个字符串拼接。

改进的空间：

如果开发中基本确定拼接后的字符串长度不高于某个限定值，可以使用StringBuilder(int highlevel)构造器来进行创建StringBuilder。

五、intern()的使用

以上的解释：

如果字符串常量池中，通过queals方法对比的时候，已经包含了这个字符串，接下来池子中的字符串将会被返回。否则就会将这个字符串加到池子里，并且返回这个字符串实例。

假如说s和t是相同的，以下两种情况结果都为true。

s.intern() == t.intern()

s.equals(t)

1.如果不是用双引号声明的String对象，可以使用String提供的intern方法：intern方法会从字符串常量池中查询当前字符串是否存在，若不存在就会将当前字符串放入常量池中。

比如：String s = new String(“I love you”).intern();

2.也就是说，如果在任意字符串上调用String.intern方法，那么其返回结果所指向的那个类实例，必须和直接以常量形式出现的字符串实例完全相同。因此，下列表达式的值必定是true：

(“a” + “b” + “c”).intern() == “abc”;

3.通俗点讲，Interned String就是确保字符串在内存里只有一份拷贝，这样可以节约内存空间，加快字符串操作任务的执行速度。注意，这个值会被存放在字符串内部池（字符串常量池）（String Intern Pool）。

如何保证变量s指向字符串常量池中的数据？

1.String s = “abc”; // 字面量方式定义。

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

String s = new StringBuilder(“abc”).toString().intern(); //调用intern方法。

new String(“abc”)会创建几个对象？

1.创建了两个对象

一个是通过new关键字在堆空间创建的。

另一个是ldc创建的字符串常量池中的对象。

2.创建了5个对象

第一个new 了StringBuilder对象（1）。

第二个new了String（4）。

第三个常量池中的a（6）。

第四个new了String（9）。

第五个常量池中的b（11）。

第六个，StringBuilder的toString()方法，也会new一个String（toString方法的调用，并不会将字符串放到字符串常量池中）。

StringBuilder的toString()方法：

toString方法的调用，并不会将字符串放到字符串常量池中。

我们并没有在字节码指令中发现ldc命令，所以并没有将字符串放到字符串常量中。

经典题目（99%的人会做错！）

结果：

jdk6：false、false。

jdk7和8：false、true。

解释：

Strign s = new String(“1”);我们已经知道，它不仅会new一个String对象在堆中，而且还会在字符串常量池中放上"1"。

所以调用s.intern();并没有什么实际意义，因为字符串常量池中已经有"1"了。

而且s指向的是new String(“1”)的地址，而不是常量池中的地址。

如果s.intern() 改为s = s.intern(); 那么s == s2就是true了。

s3的地址记录的实际是new String(“11”)。此时，字符串常量池中并不存在"11"，只存在"1"，因为字符串拼接使用StringBuilder之后调用的toString()方法，并不会将结果存在字符串常量池中。

s3.intern();会将"11"存在字符串常量池中。jdk6中就是创建了一个常量池中新的对象"11"，也就有新的地址；jdk7和8常量池放到堆中了，这里s3调用intern()方法，这里由于空间节省，常量池中并不会创建"11"，而是创建了一个指向堆空间new String(“11”)的地址。

String s4 = “11”; s4指向的地址是上一行代码在常量池中存放的"11"。

jdk7和8中，本质上s3和s4指向了堆中同一个地址。

详细过程：

拓展：

原因：

String s4 = “11”; 是实打实的在字符串常量池中创建了"11"，而不是一个引用了。

s3.intern(); 因为常量池中已经有"11"了。

此时s3指向堆中的new String(“11”); s4指向常量池中的"11"，s5也指向常量池中的"11"。

总结String的intern()的使用：

1.jdk1.6中，将这个字符串对象尝试放入字符串常量池。

如果串池中有，则并不会放入，返回已有的串池中的对象的地址。

如果没有，会把此对象复制一份，放入串池，并返回串池中的对象地址。

2.jdk1.7起，将这个字符串对象尝试放入串池。

如果串池中有，则并不会放入，返回已有的串池中的对象地址。

如果没有，则会把对象的引用地址复制一份，放入串池，并返回串池中的引用地址。

intern练习1：

jdk6：true、false

jdk7：true、true（jdk7在串池并没有创建"ab"对象，而是创建了一个引用，指向堆中的new String(“ab”)的地址）

在代码前面加上String x = “ab”;

intern练习2：

第一种情况是false,第二种情况是true。

String s1 = new String(“ab”); 会在堆中new 一个String，并且也会在字符串常量池中新建一个"ab"。

String s1 = new String(“a”) + new String(“b”); 会在字符串常量池中新建"a"、“b”，拼接字符串使用StringBuilder，其toString()方法并不会在常量池中创建"ab"。而且调用s1.intern()之后，jdk7由于堆中已经有ab字符串了，在字符串常量池只创建了一个该对象的引用。

六、intern()效率测试

空间角度（jdk1.8）

使用jvisualvm查看结果：

不使用intern：

使用intern：

总结：使用intern更节省内存空间（尤其是程序中有大量重复的字符串时），并且执行速度还快。

七、StringTable的垃圾回收

使用jvm参数：

-XX:+PrintStringTableStatistics，打印字符串常量池信息。

main函数中什么也不写的字符串常量池打印信息：

执行以下代码：

执行以下代码：

我们会发现发生了GC，并且字符串常量池数据量降了下来

八、G1中的String去重操作

1.背景：对许多Java应用（有大的也有小的）做的测试得出以下结果：

堆存活数据集合里面String对象占了25%。

堆存活数据集合里面重复的String对象有13.5%。

String对象的平均长度是45。

2.许多大规模的Java应用的瓶颈在于内存，测试表明，在这些类型的应用里面，Java堆中存活的数据集合差不多25%是String对象。更进一步，这里面差不多一半String对象是重复的，重复的意思是说：string1.equals(string2)=true。堆上存在重复的String对象必然是一种内存的浪费。这个项目将在G1垃圾收集器中实现自动持续对重复的String对象进行去重，这样就能避免浪费内存。

实现

1.当垃圾收集器工作的时候，会访问堆上存活的对象。对每一个访问的对象都会检查是否是候选的要去重的String对象。

2.如果是，把这个对象的一个引用插入到队列中等待后续的处理。一个去重的线程在后台运行，处理这个队列。处理队列的一个元素意味着从这个队列删除这个元素，然后尝试去重它引用的String对象。

3.使用一个hashtable来记录所有的被String对象使用的不重复的char数组。当去重的时候，会查这个hashtable，来看堆上是否已经存在一个一模一样的char数组。

4.如果存在，String对象会被调整引用那个数组，释放对原来的数组的引用，最终会被垃圾收集器回收掉。

5.如果查找失败，char数组会被插入到hashtable，这样以后的时候就可以共享这个数组了。

命令行选项

UseStringDeduplication(bool)：开启String去重，默认是不开启的，需要手动开启。

PrintStringDeduplicationStatistics(bool)：打印详细的去重统计信息。

StringDeduplicationAgeThreshold(uintx)：达到这个年龄的String对象被认为是去重的候选对象。