《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 jianshu.com/p/a80c9b2b89cd 「叫我不矜持」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

前言

最近在突然想到了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;
文章目录
  1. 1. 前言
  2. 2. 一.问题
    1. 2.1. 案例1
    2. 2.2. 案例2
  3. 3. 二.探究问题
  4. 4. 三.总结