java字符串拼接_字符串拼接，什么时候会走StringBuilder？

☞ 程序员进阶必备资源免费送「21种技术方向！」 ☜

粉丝福利：

专属优惠码4折优惠，当当网买书满400-230(点击查看)

前言

最近在突然想到了 String 字符串拼接问题，于是做了一个 demo 测试了一下，到底 String 类型的字符串在拼接的时候，哪种情况下会走会走 StringBulider 进行字符串拼接，而哪种情况编译器会对代码进行优化？话不多说，先看 demo

一. 问题

案例 1

测试代码 1.png

可以发现，str == str2 的结果为 false，那么我们在看看下一个例子。

案例 2

测试代码 2.png

这时候，两个字符串对比的结果为 true。

二. 探究问题

这时候，疑问就来了，为什么结果会不一致呢？*利用在 cmd 窗口输入 javap -c TestDemo.class 命令，对字节码文件进行反编译，发现了问题所在？*

测试代码 1cmd.png

可以看到在案例 1 中，java 代码底层走了 StringBuilder，进行字符串拼接，然后调用了 StringBuilder 的 toString 方法。

测试代码 2cmd.png

而案例 2 中，对 class 文件进行反编译，发现代码出现了一点变化，并没有走 StringBuilder 进行字符串拼接。

三. 总结

1、案例 1 中，通过变量和字符串拼接，java 是需要先到内存找变量对应的值，才能进行完成字符串拼接的工作，这种方式 java 编译器没法优化，只能走 StringBuilder 进行拼接字符串，然后调用 toString 方法，当然返回的结果和常量池中的 111 这个字符串的内存地址是不一样的，因此结果为 false。

2、案例 2 中，直接在表达式里写值，java 不用根据变量去内存里找对应的值，可以在编译的时候直接对这个表达式进行优化，优化后的表达式从 "111" + ""直接变成了"111" ，两个 String 类型的变量都指向了常量池的 111 字符串，因此结果为 true;

以上，便是今天的分享，希望大家喜欢，觉得内容不错的，欢迎点击「在看」支持，谢谢各位。

喜欢文章，点个在看