这是个人第 50 篇原创文章。
我想全部 Java 程序员都曾被这个 new String 的问题困扰过,这是一道高频的 Java 面试题,但惋惜的是网上众说纷纭,居然找不到标准的答案。有人说建立了 1 个对象,也有人说建立了 2 个对象,还有人说可能建立了 1 个或 2 个对象,但谁都没有拿出干掉对方的证据,这就让咱们这帮吃瓜群众们陷入了两难之中,不知道到底该信谁得。
可是今天,老王就斗胆和你们聊聊这个话题,顺便再拿出点证据。
以目前的状况来看,关于 new String("xxx") 建立对象个数的答案有 3 种:java
字符串的分配和其余的对象分配同样,须要耗费高昂的时间和空间为代价,若是须要大量频繁的建立字符串,会极大程度地影响程序的性能,所以 JVM 为了提升性能和减小内存开销引入了字符串常量池(Constant Pool Table)的概念。
字符串常量池至关于给字符串开辟一个常量池空间相似于缓存区,对于直接赋值的字符串(String s="xxx")来讲,在每次建立字符串时优先使用已经存在字符串常量池的字符串,若是字符串常量池没有相关的字符串,会先在字符串常量池中建立该字符串,而后将引用地址返回变量,以下图所示:
以上说法能够经过以下代码进行证实:git
public class StringExample { public static void main(String[] args) { String s1 = "Java"; String s2 = "Java"; System.out.println(s1 == s2); } }
以上程序的执行结果为:true,说明变量 s1 和变量 s2 指向的是同一个地址。
在这里咱们顺便说一下字符串常量池的再不一样 JDK 版本的变化。
常量池的内存布局程序员
从JDK 1.7 以后把永生代换成的元空间,把字符串常量池从方法区移到了 Java 堆上。
JDK 1.7 内存布局以下图所示:github
JDK 1.8 内存布局以下图所示:面试
JDK 1.8 与 JDK 1.7 最大的区别是 JDK 1.8 将永久代取消,并设立了元空间。官方给的说明是因为永久代内存常常不够用或发生内存泄露,会爆出 java.lang.OutOfMemoryError: PermGen 的异常,因此把将永久区废弃而改用元空间了,改成了使用本地内存空间,官网解释详情:http://openjdk.java.net/jeps/122
答案解密缓存
认为 new 方式建立了 1 个对象的人认为,new String 只是在堆上建立了一个对象,只有在使用 intern() 时才去常量池中查找并建立字符串。
认为 new 方式建立了 2 个对象的人认为,new String 会在堆上建立一个对象,而且在字符串常量池中也建立一个字符串。
认为 new 方式有可能建立 1 个或 2 个对象的人认为,new String 会先去常量池中判断有没有此字符串,若是有则只在堆上建立一个字符串而且指向常量池中的字符串,若是常量池中没有此字符串,则会建立 2 个对象,先在常量池中新建此字符串,而后把此引用返回给堆上的对象,以下图所示:性能优化
老王认为正确的答案:建立 1 个或者 2 个对象。
技术论证
解铃还须系铃人,回到问题的那个争议点上,new String 到底会不会在常量池中建立字符呢?咱们经过反编译下面这段代码就能够得出正确的结论,代码以下:ide
public class StringExample { public static void main(String[] args) { String s1 = new String("javaer-wang"); String s2 = "wang-javaer"; String s3 = "wang-javaer"; } }
首先咱们使用 javac StringExample.java 编译代码,而后咱们再使用 javap -v StringExample 查看编译的结果,相关信息以下:布局
Classfile /Users/admin/github/blog-example/blog-example/src/main/java/com/example/StringExample.class Last modified 2020年4月16日; size 401 bytes SHA-256 checksum 89833a7365ef2930ac1bc3d7b88dcc5162da4b98996eaac397940d8997c94d8e Compiled from "StringExample.java" public class com.example.StringExample minor version: 0 major version: 58 flags: (0x0021) ACC_PUBLIC, ACC_SUPER this_class: #16 // com/example/StringExample super_class: #2 // java/lang/Object interfaces: 0, fields: 0, methods: 2, attributes: 1 Constant pool: #1 = Methodref #2.#3 // java/lang/Object."<init>":()V #2 = Class #4 // java/lang/Object #3 = NameAndType #5:#6 // "<init>":()V #4 = Utf8 java/lang/Object #5 = Utf8 <init> #6 = Utf8 ()V #7 = Class #8 // java/lang/String #8 = Utf8 java/lang/String #9 = String #10 // javaer-wang #10 = Utf8 javaer-wang #11 = Methodref #7.#12 // java/lang/String."<init>":(Ljava/lang/String;)V #12 = NameAndType #5:#13 // "<init>":(Ljava/lang/String;)V #13 = Utf8 (Ljava/lang/String;)V #14 = String #15 // wang-javaer #15 = Utf8 wang-javaer #16 = Class #17 // com/example/StringExample #17 = Utf8 com/example/StringExample #18 = Utf8 Code #19 = Utf8 LineNumberTable #20 = Utf8 main #21 = Utf8 ([Ljava/lang/String;)V #22 = Utf8 SourceFile #23 = Utf8 StringExample.java { public com.example.StringExample(); descriptor: ()V flags: (0x0001) ACC_PUBLIC Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V 4: return LineNumberTable: line 3: 0 public static void main(java.lang.String[]); descriptor: ([Ljava/lang/String;)V flags: (0x0009) ACC_PUBLIC, ACC_STATIC Code: stack=3, locals=4, args_size=1 0: new #7 // class java/lang/String 3: dup 4: ldc #9 // String javaer-wang 6: invokespecial #11 // Method java/lang/String."<init>":(Ljava/lang/String;)V 9: astore_1 10: ldc #14 // String wang-javaer 12: astore_2 13: ldc #14 // String wang-javaer 15: astore_3 16: return LineNumberTable: line 5: 0 line 6: 10 line 7: 13 line 8: 16 } SourceFile: "StringExample.java"
备注:以上代码的运行也编译环境为 jdk1.8.0_101。
其中 Constant pool 表示字符串常量池,咱们在字符串编译期的字符串常量池中找到了咱们 String s1 = new String("javaer-wang"); 定义的“javaer-wang”字符,在信息 #10 = Utf8 javaer-wang 能够看出,也就是在编译期 new 方式建立的字符串就会被放入到编译期的字符串常量池中,也就是说 new String 的方式会首先去判断字符串常量池,若是没有就会新建字符串那么就会建立 2 个对象,若是已经存在就只会在堆中建立一个对象指向字符串常量池中的字符串。
那么问题来了,如下这段代码的执行结果为 true 仍是 false?性能
String s1 = new String("javaer-wang"); String s2 = new String("javaer-wang"); System.out.println(s1 == s2);
既然 new String 会在常量池中建立字符串,那么执行的结果就应该是 true 了。其实并非,这里对比的变量 s1 和 s2 堆上地址,由于堆上的地址是不一样的,因此结果必定是 false,以下图所示:
从图中能够看出 s1 和 s2 的引用必定是相同的,而 s3 和 s4 的引用是不一样的,对应的程序代码以下:
public static void main(String[] args) { String s1 = "Java"; String s2 = "Java"; String s3 = new String("Java"); String s4 = new String("Java"); System.out.println(s1 == s2); System.out.println(s3 == s4); }
程序执行的结果也符合预期:
true
false
扩展知识
咱们知道 String 是 final 修饰的,也就是说必定被赋值就不能被修改了。但编译器除了有字符串常量池的优化以外,还会对编译期能够确认的字符串进行优化,例如如下代码:
public static void main(String[] args) { String s1 = "abc"; String s2 = "ab" + "c"; String s3 = "a" + "b" + "c"; System.out.println(s1 == s2); System.out.println(s1 == s3); }
按照 String 不能被修改的思想来看,s2 应该会在字符串常量池建立两个字符串“ab”和“c”,s3 会建立三个字符串,他们的引用对比结果也必定是 false,但其实不是,他们的结果都是 true,这是编译器优化的功劳。
一样咱们使用 javac StringExample.java 先编译代码,再使用 javap -c StringExample 命令查看编译的代码以下:
警告: 文件 ./StringExample.class 不包含类 StringExample Compiled from "StringExample.java"
public class com.example.StringExample {
public com.example.StringExample();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: ldc #7 // String abc
2: astore_1
3: ldc #7 // String abc
5: astore_2
6: ldc #7 // String abc
8: astore_3
9: getstatic #9 // Field java/lang/System.out:Ljava/io/PrintStream;
12: aload_1
13: aload_2
14: if_acmpne 21
17: iconst_1
18: goto 22
21: iconst_0
22: invokevirtual #15 // Method java/io/PrintStream.println:(Z)V
25: getstatic #9 // Field java/lang/System.out:Ljava/io/PrintStream;
28: aload_1
29: aload_3
30: if_acmpne 37
33: iconst_1
34: goto 38
37: iconst_0
38: invokevirtual #15 // Method java/io/PrintStream.println:(Z)V
41: return
}
从 Code 三、6 能够看出字符串都被编译器优化成了字符串“abc”了。
总结
本文咱们经过 javap -v XXX 的方式查看编译的代码发现 new String 首次会在字符串常量池中建立此字符串,那也就是说,经过 new 建立字符串的方式可能会建立 1 个或 2 个对象,若是常量池中已经存在此字符串只会在堆上建立一个变量,并指向字符串常量池中的值,若是字符串常量池中没有相关的字符,会先建立字符串在返回此字符串的引用给堆空间的变量。咱们还将了字符串常量池在 JDK 1.7 和 JDK 1.8 的变化以及编译器对肯定字符串的优化,但愿能帮你正在的理解字符串的比较。
最后的话
原创不易,本篇近 3000 的文字描述,以及大量精美的图片,耗费了做者大概 5 个多小时的时间,写做是一件很酷,而且能帮助他人的事,做者但愿一直能坚持下去。若是以为有用,请随手点击一个赞吧,谢谢。
END
史上最全的延迟任务实现方式汇总!附代码(强烈推荐)
99%的程序员都在用Lombok,原理居然这么简单?我也手撸了一个!|建议收藏!!!
《大厂内部资料》Redis 性能优化的 13 条军规!全网首发
关注公众号发送”进群“,老王拉你进读者群。