JVM字符串常量池StringTable

本是古典何须时尚 2024-03-27 18:48 82阅读 0赞

**目录**

一、StringTable为什么要调整

二、String的基本特性

三、String的内存分配

四、字符串拼接操作

五、intern()方法

六、Stringtable的垃圾回收

七、G1中String去重操作

--------------------

## 一、StringTable为什么要调整 ##

jdk7之前，hotspot对于方法区的实现是永久代，常量池包括字符串常量池放于永久代中；

jdk7时，hotspot将字符串常量池（还有静态变量）放在了堆中。有一点“去永久代”的苗头

jdk8之后，hotspot取出永久代，取而代之的是使用本地内存的元空间。字符串常量池还是在堆中。

为什么要将字符串常量池StringTable放在堆中？

jdk7中将StringTable放到了堆空间中，因为永久代的回收效率很低。在fullGC的时候才触发，而fullGC是老年代空间不足，永久代不足时才触发，触发次数较少，甚至在开发中我们要避免出现fullGC。这就导致了StringTable回收效率不高，而我们开发中会创建大量的字符串，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。

## 二、String的基本特性 ##

jdk8及以前，内部定义了final char\[\] value用于存储字符串数据

JDK9时改为byte\[\] + 字符类型标记，为什么做出这个改变呢？

char数组一个char占16bits（两个字节），String是堆空间的主要部分，大部分是latin-1字符，一个字节就够了，这样会有一半空间浪费。所以采用byte数组+字符串类型，如果是中文等UTF-16 的用两个字节存储。

StringBuffer，StringBuilder同样做了修改

String为什么不可变？

因为底层数组被final修饰。而且其类自身也被final修饰，这就导致了不能通过继承去修改其内部结构。保证了其不可变性。

*  当字符串重新赋值，需要重写指定内存区域赋值，不能使用原有的value进行赋值
 *  当对现有的字符串进行连接操作时，也需要重新指定内存区域赋值，不能对使用原有的value进行赋值
 *  当调用String的replace方法修改指定字符或字符串时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值。

字符串常量池中不会存储相同的字符串的

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

*  \-XX:StringTableSize可设置StringTable的大小
 *  JDK6固定1009，jdk7中StringTable默认的长度是60013,JDK8时默认是60013，1009是可设置的最小值

## 三、String的内存分配 ##

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

String的常量池比较特殊，主要使用方法有两种

*  直接使用双引号，声明出来的String对象会直接存储在常量池中
 *  如果不是双引号声明的String对象，可以使用String提供的intern()方法

jdk6及之前，字符串常量池存在永久代

jdk7中，字符串常量池调整到Java堆中，调优时仅需调整堆大小就可以

## 四、字符串拼接操作 ##

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

![e279a1afbdd641dc86e5ed783e076edb.png][]

只要其中有一个变量，拼接结果就在堆中（常量池以外的堆），变量的拼接原理是StringBuilder

![db8ac2404c114791aef8deb9efeb1f36.png][]

String res  = s1 + s2; 
    // 实际上是StringBuilder s = new StringBuilder().append(s1).append(s2); 
    // 然后调用s.toString();

![fa75e35816fb42f084b7718edde3389a.png][]

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

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

针对final修饰类，方法，基本数据类型，引用数据类型变量的结构时，能使用final尽量使用上

![14e6c08358e04e4fbcd173f3e5cc7a29.png][]

## 五、intern()方法 ##

jdk1.6中，将这个字符串对象放入串池

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

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

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

**例子：**

![d870b6f9fe1642178a6a1d578bb7c68c.png][]

> **前置知识**
> 
> newString("ab")会创建几个对象？
> 
> 2个对象，查看字节码验证。一个是常量池ab，一个是new出来在堆空间。（前提是常量池没有ab）
> 
> new String("a")+new String("b")?
> 
>  *  对象1，有拼接操作就newStringBuilder
>  *  对象2，new一个String
>  *  对象3，常量池a
>  *  对象4，new String
>  *  对象5，常量池b
>  *  对象6，StringBuilder，toString方法会new String返回
>     
>      *  注意：toString方法这里new String并不会向字符串常量池中放入"ab"，不像我们平时上面一样会放入一个“ab”在常量池中。

**结果**

jdk6 false false

jdk7/8 false true

**分析：**

jdk6的intern会复制一份"1"放入字符串常量池。但是new的时候其实已经放入常量池了，所以这里intern没啥用，此时s2拿到的就是常量池的那一份。而s是指向堆中new出来的String对象，所以为false

s3这里intern的时候常量池没有“11”，所以会复制一份放入常量池，此时s4拿到的就是常量池的那一份。而s3指向堆中new出来的String对象，所以为false

jdk7/8的intern是复制引用地址放入字符串常量池，但是new的时候其实已经放入常量池了，所以这里intern没啥用，此时s2拿到的就是常量池的那一份。所以为false

s3这里intern的时候常量池没有“11”，所以会复制引用放入常量池，此时s4拿到的就是常量池的那一份引用。而s3也指向堆中new出来的String对象，所以为true

## 六、Stringtable的垃圾回收 ##

\-XX:+PrintStringTableStatistics

## 七、G1中String去重操作 ##

背景：对许多Java应用，做的测试结果如下

*  堆存货数据集合里面String对象占了25%
 *  堆存活数据集合里面重复的String对象有13.5%
 *  String对象的平均长度是45

许多大规模的Java应用的瓶颈在于内存。Java堆中存活的数据集合差不多25%是String对象，这里差不多一半的String对象是重复的， 重复是指equals方法=true,堆上重复的String对象必然是一种内存的浪费。G1垃圾收集器中实现自动持续对重复的String对象进行去重，这样避免浪费。

[e279a1afbdd641dc86e5ed783e076edb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/034465edaa3b4072bc46a7b55c47488c.png
[db8ac2404c114791aef8deb9efeb1f36.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/2e4c7d6424d041a3af0537da3b1d4c5f.png
[fa75e35816fb42f084b7718edde3389a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/7835706f995e47479c06170cd2a12f8e.png
[14e6c08358e04e4fbcd173f3e5cc7a29.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/ef35008ac855459e8241302c28abf3d9.png
[d870b6f9fe1642178a6a1d578bb7c68c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/a49d06c8c7624e8bae36ada2d7052abd.png