String不可变依赖整套设计：final class封继承、private字段隔离访问、所有方法返回新对象、构造时防御性拷贝；仅final修饰数组引用并不保证内容不可变。
String不可变不是靠final一个词撑起来的
很多人看到private final char[] value就以为“加了final当然不可变”，这是典型误解。final只锁住数组引用，不锁内容——你完全可以用反射改value[0]（虽然不推荐）。真正让String“稳如泰山”的是一整套设计协同：final class封死继承、private字段隔绝外部访问、所有方法（substring、replace、concat）全部返回新对象、构造时还做防御性拷贝（Arrays.copyOf），连传入的char[]都不直接引用。
为什么JVM敢把"hello"反复复用？
字符串常量池能正常工作，全靠不可变性兜底。如果String可变，下面这段代码就会出大事：
String a = "test";
String b = "test";
// 假设String可变，有人偷偷执行了：a.setValue(new char[]{'h', 'a', 'c', 'k'});
System.out.println(b); // 你猜输出啥？
结果b也会变成"hack"——因为a和b指向常量池里同一个对象。不可变性让JVM敢于共享，省内存、提性能，也避免了这种诡异副作用。
拼接字符串时+和StringBuilder到底差在哪？
不是语法问题，是对象生命周期问题：
立即学习“Java免费学习笔记（深入）”；
-
str += "x"每次都在堆上新建String对象，原对象若无引用，就进GC队列 - 循环里写
for (int i=0; i，会创建约1000个中间String和StringBuilder对象 -
StringBuilder内部用可变char[]，扩容可控，最后调.toString()才生成一个最终String
所以高频拼接必须显式用StringBuilder，别指望编译器优化——它只对编译期确定的字面量+做合并（比如"a"+"b"+"c"）。
安全场景下，String的不可变反而成了隐患？
是的，矛盾点就在这里：不可变保证了传递过程不被篡改，但也导致敏感数据（比如密码）一旦生成，就一直留在堆里，直到GC——而GC时间不可控，可能被dump出来。
所以实际开发中：
- 密码、token这类数据，优先用
char[]接收，用完立刻Arrays.fill(pwd, '\u0000')清空 - 别用
String password = scanner.nextLine()，哪怕只是临时存一下 -
String适合做key、路径、SQL模板等“只读标识”，不适合做“临时载荷”
不可变性不是银弹，它是以牺牲“内存及时清理能力”为代价，换来了线程安全、哈希稳定和语义确定性——用在哪，得看清楚代价落谁身上。
