时间:2021-05-19
字符串常量池是 JVM中的一个重要结构,用于存储JVM运行时产生的字符串。在JDK7之前在方法区中,存储的是字符串常量。而字符串常量池在 JDK7开始移入堆中,随之而来的是除了存储字符串常量外,还可以存储字符串引用(因为在堆中,引用堆中的字符串常量很方便,所以可以存储引用)。这使得很多字符串的操作在 JDK7中和在之前的版本中执行是不同的结果。这也是为什么字符串相关的问题是如此具有迷惑性的原因之一。
String:在 JDK9之前,String底层是使用 char数组来存储字符串数据的,而在 JDK9开始,使用 byte数组+编码来代替 char数组,这是为了节省空间,因为不同编码的数据占空间不一样,很多单位数据只需要一个 byte(8字节) 就可以存储,而使用 char(16字节)就会浪费多余的空间。
字符串常量池:底层使用 HashTable来存储字符串,在 JDK6 HashTable的数组长度是1006,JDK7开始变成了 60013,这是为了避免存储字符串过多导致链表长度过长从而查询效率降低。可以使用参数 -XX:StringTableSize=来设置 StringTable数组的长度。
1、对于字符串常量相加,编译器会优化成直接相加。
如 String ss = "a" + "b",在编译器的优化下,实际上只会创建一个 "ab" 字符串。
而 final String s1 = "a"; String s2 = s1+"b",除了创建字符串 "a"外,只会创建 "ab"。
操作相关字符串如下:
可以看到只对字符串 "a"、"ab"进行了入池操作(ldc)
2、对于包含字符串变量的相加,不会在字符串常量池中创建对应的字符串。
如 String s1 = "a"; String s2 = s1 + "b",执行完后字符串常量池中只会包含 "a"、"b" 字符串。
对于 s1 + "b",下面是其字节码操作
可以看到,相加操作实际上是调用 StringBuilder的append方法进行字符串拼接,然后调用它的 toString方法获取返回值保存输出,期间并没有入池操作(ldc)。
由此得出的优化建议:因为每次执行一次包含非常量的字符串相加时,都进行了一次 StringBuilder对象的创建,所以如果需要多次连接,可以直接创建 StringBuilder对象,使用一个 StringBuilder对象进行字符串拼接,避免创建多个对象降低效率。
对象,包括 new的对象以及字符串对象。
1、对于String ss = new String ("ab"),这个过程首先会在会在字符串常量池中创建一个 "ab"字符串常量,然后再在堆上创建一个 new String()的对象,在这个对象中会保存常量池中 "ab"的地址信息,最后在栈上创建一个局部变量 ss ,保存堆中创建的对象地址。所以全程创建了堆中的一个对象和字符串常量池中的一个对象。
2、new String("a") + new String("b")。严格来看,创建了六个对象。
首先new String("a")和 new String("b") ,分为创建了两个对象。两者相加时,会创建一个 StringBuilder对象,而在 StringBuilder.toString()方法中,也会创建一个 String对象
3、String s1 = "a", String s2 = "b", String s3 = "a" + "b" + s1 + "c" + s2;对应的字节码如下:
字符串常量池中会有四个字符串对象,分别是 "a"、"b"、"ab"、"c"。在开始因为 s1、s2的赋值,会将 "a"、"b"分别加入字符串常量池,然后执行第三步,运行顺序是从左到右,首先执行 "a" + "b" ,因为两个都是常量,所以会因为编译器的优化直接返回 "ab",并且因为计算的两个参数都是常量,所以直接加入字符串常量池,随后因为与变量 s1相加,所以调用 StringBuilder的append方法,得到的结果保存到局部变量表中,所以引入常量 "c",因为是常量,所以还是会引入字符串常量池,然后与前面拼接得到的结果再次拼接,最后再与变量 s2相加,因为不是常量所以还是不会将结果加入字符串常量池。
除此之外,还需要注意,上面三种情况是在初始情况下,也就是字符串常量池中没有要加入的字符串时的场景,如果字符串常量池中预先就包含要加入的字符串,那么就会直接将常量池中的对应的字符串地址返回给调用方。比如 String s1 = "a",在常量池中没有 "a"时,创建的对象是 1个,而如果常量池中已经存在,那么就会将其地址直接返回赋给 s1。那么创建的对象就是 0个了。
intern()方法是 String类的一个native方法,作用是尝试将调用这个方法的字符串对象加入字符串常量池中,然后返回常量池中存储的值。在开头说过,在 JDK7开始字符串常量池可以存储字符串引用,导致字符串操作的过程可能会之前不一样,从而得到不同的结果。
intern()方法的执行:
1.6及之前:尝试将当前字符串常量加入常量池,如果常量池存在就返回地址值;如果不存在就先加入常量池,然后再返回加入位置的地址值。
1.7开始:尝试将当前字符串常量加入常量池,如果存在就将返回地址值;如果不存在就存入当前 String 字符串的地址值。
下面以一个例子来解释一下,在JDK7和JDK7之前下面代码执行分别是什么结果。
@Test public void test1(){ String s = new String("1"); s.intern(); String s2 = "1"; System.out.println(s == s2); String s3 = new String("1") + new String("1"); s3.intern(); String s4 = "11"; System.out.println(s3 == s4); }先说结论:
JDK7之前: false、false。
JDK7及之后:false、true。
原因:
1、首先先看上面 3------6行的,首先,第三行会在字符串常量池中添加 "1" ,然后在堆中创建一个对象,保存 "1"在常量池中的地址,再在局部变量表中添加一个 s保存堆中对象的地址。随后执行第四行,此时 s指向的字符串已经在常量池中了,所以这一步无效,第五行因为常量池已经存在 "1" ,所以 JDK7或之前执行的逻辑是一样的,直接将 "1"在常量池中的地址返回给 s2。然后判断,s指向的是堆中的对象,而 s2指向的是常量池中的字符串常量,所以无论是 JDK7还是之前的都是 false。
2、然后再看下面 9-----12行。因为前面已经在常量池中添加 "1",所以第9行会直接返回地址,然后执行添加操作,创建字符串 "11",此时并没有添加到常量池,然后执行第10行,因为常量池不存在 "11",所以 JDK7之前直接加入常量池,JDK7及以后则直接将 "11"的地址存入常量池,而 s3则不变,还是保存的是常量池外的那个 "11"的地址值。然后执行 11行,因为常量池已存在 "11",所以 s4就是返回 "11"的地址值,不同的是在 JDK7之前因为常量池保存的是 "11"常量,所以返回的是常量池中的地址值;而 JDK7 及以后常量池保存的是常量池外的 "11"的地址值,所以返回的是池外的地址值。所以最后判断在 JDK7之前是 false,而在 JDK7开始是 true。
到此这篇关于JVM 中的StringTable的文章就介绍到这了,更多相关JVM 中的StringTable内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
本文研究的主要是JVM中的flag设置详解的相关内容,具体介绍如下。一、堆大小设置-Xmx3550m:设置JVM最大可用内存为3550M。-Xms3550m:设
一、Jvm调优。参考文章1、先看一下未设置JVM参数的情况,默认情况下,没有设置任何Jvm参数。idea中安装VisualVM监控jvm的图文教程2、设置Jvm
Java垃圾回收与对象生命周期详解Java中的垃圾回收与对象生命周期1.垃圾回收垃圾回收是Java程序设计中内存管理的核心概念,JVM的内存管理机制被称为垃圾回
1、说明比较基本类型==,比较对象值推荐equals或compareTo。首先,Java中的数据存储在JVM中,而基本类型的数据存储在JVM的局部变量表中,也可
之前的Java垃圾回收之标记清除算法详解会导致内存碎片。下文的介绍的coping算法可以解决内存碎片问题。概述如果jvm使用了coping算法,一开始就会将可用