在Java中String为什么不可变_JavaString底层原理解析_技术教程

String不可变性由private、final引用、无修改方法三重防护协同实现，缺一不可；JDK9改用byte[]是为内存减负，依赖不可变性保证编码稳定；常量池复用、线程安全、hashCode缓存等均为其自然红利。

String 的不可变性不是靠 final 一个词撑起来的

很多人看到 private final char[] value 就以为“final 数组 = 内容不能改”，这是典型误解。final 只锁住数组引用，不锁数组元素——value[0] = 'x' 在语法上完全合法（除非被封装挡住）。String 真正的不可变，是靠三重防护协同实现的：

private：外部类连 value 字段都看不到，更别说读写
final 引用：保证构造后 value 不会指向别的数组
无任何 public 修改方法：没有 setCharAt()、没有 replaceInPlace()，所有操作如 substring()、replace() 都返回新对象

这三者缺一不可。少一个，比如去掉 private，反射就能直接改；少 final，子类可能偷偷换掉整个数组；少第三点，光靠封装也拦不住设计好的修改入口。

为什么 JDK 9 把 char[] 换成 byte[]？和不可变性有关吗？

有关，但不是为了“加强不可变”，而是为内存减负——而减负的前提，恰恰依赖不可变性。

JDK 9 引入了紧凑字符串（Compact Strings），内部用 private final byte[] value + private final byte coder（标识 LATIN1 或 UTF16）替代原来的 char[]。对纯 ASCII 字符串（比如 "user_id", "HTTP"），每个字符只占 1 字节，省一半内存。

这个优化敢做，是因为 String 不可变：一旦构造完成，coder 就永远确定，不会因后续修改而动态切换编码；也不会出现“一半 LATIN1、一半 UTF16”的脏状态。如果 String 可变，这种底层编码优化根本不敢上。

常量池复用和线程安全，都是不可变性的“副产品”

这两点不是设计目标，而是不可变性自然带来的红利，但它们反向验证了设计的必要性：

字符串常量池失效：如果 String a = "hello" 和 String b = "hello" 共享同一对象，而你又能改 a 的内容，b 就会意外变成 "world" —— JVM 直接崩溃
多线程读写冲突：像 public static final String DB_URL = "jdbc:mysql://..." 这种全局配置，多个线程并发读取时，不用加锁、不用 volatile，因为没人能改它
hashCode 缓存失效：String 的 hash 字段是懒计算且只算一次，如果字符串可变，每次 HashMap.get() 都得重算 hash，性能断崖下跌

反射真能改 String 吗？能，但别在生产环境试

可以。通过反射获取 value 字段，再用 Array.set() 或直接赋值，确实能篡改内容：

String s = "Hello";
Field valueField = String.class.getDeclaredField("value");
valueField.setAccessible(true);
char[] value = (char[]) valueField.get(s);
value[0] = 'h'; // 现在 s.toString() 会输出 "hello"

但这属于破坏契约的 hack 行为：