Java引用传递误区：String为何表现像值传递

Java中String并非“像值传递”，而是严格遵循所有对象都按值传递引用的规则；所谓“表现像值传递”的错觉，实则源于String的不可变性——每次操作（如拼接、大小写转换）都生成新对象并让变量指向它，而非修改原对象；相比之下，可变的StringBuilder才能真正展现引用传递的本质：多个引用共享同一对象并相互影响；同时，字符串常量池与new String()的内存差异进一步加剧了对==比较的误解，提醒开发者必须区分引用相等与内容相等，并在性能敏感场景下善用StringBuilder避免对象爆炸。

Java中String真的按值传递吗？

不是“像”，而是它根本就是按值传递——所有Java对象都如此。所谓“String表现像值传递”，其实是误读了String的不可变性（immutability）和引用变量的赋值行为。当你写str1 = str2，复制的是引用值（即堆中对象地址的副本），不是对象本身；但因为String方法（如substring、toUpperCase）从不修改原对象，而是返回新对象，所以看起来“原变量没变”。

常见错误现象：为什么修改str后另一个引用没跟着变？

典型场景是误以为String可被“内部修改”：

String a = "hello";
String b = a;
a = a + " world"; // 实际创建新String对象，a指向新地址
// 此时b仍是"hello"，没变

这不是引用传递失效，而是a这个变量被重新赋值了。真正体现引用本质的情况是：

• 多个变量指向同一个String字面量（如"abc"），它们共享字符串常量池中的同一实例
• 用new String("abc")会绕过常量池，产生独立对象，哪怕内容相同
• ==比较的是引用是否相同，.equals()才比内容

对比StringBuilder：为什么它才暴露引用传递本质？

StringBuilder是可变的，能清晰看到引用传递的效果：

StringBuilder sb1 = new StringBuilder("hi");
StringBuilder sb2 = sb1; // sb2和sb1指向同一对象
sb1.append(" there"); // 修改原对象内容
// 此时sb2.toString()也是"hi there"

关键区别在于：String所有“修改”操作都返回新对象，而StringBuilder.append()直接改内部字符数组。所以别拿String去验证“引用能否影响原对象”——它天生就不允许你影响原对象。

• 不要用==判断String内容相等，除非你明确在比较是否为同一常量池项
• 频繁拼接用StringBuilder，不是为了“传引用”，而是避免无谓创建大量临时String对象
• 函数参数传String时，方法内对形参重赋值（如s = s + "x"）绝不会影响调用方的实参变量

容易被忽略的细节：字符串常量池与new String()的陷阱

很多人以为String s = "abc"和String s = new String("abc")只是写法不同，其实内存行为完全不同：

• "abc"字面量一定进常量池；多次出现，复用同一对象
• new String("abc")一定在堆上新建对象，即使常量池已有"abc"
• new String("abc").intern()会强制把该字符串加入常量池（如果不存在），并返回池中引用
• 所以new String("abc") == "abc"是false，但new String("abc").intern() == "abc"是true

这跟“传递方式”无关，但直接影响你对==结果的预判，尤其在单元测试或缓存键比较时容易栽跟头。

今天关于《Java引用传递误区：String为何表现像值传递》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！