String不可变性由final类、private final字段、防御性拷贝、无写方法及哈希缓存与常量池协同保障，支撑安全、线程安全、性能优化等核心机制。
Java 中 String 的不可变性，不是靠单个 final 关键字撑起来的，而是 JDK 源码里层层设防、环环相扣的设计哲学体现——它是一套由封装、限制、缓存与契约共同构成的“防御性架构”。
1. final 类 + private final 字段：封死继承与直接篡改路径
源码中第一眼就能看到：
public final class String implements ...private final byte[] value;private final byte coder;
这两处 final 各司其职：
- 类被 final 修饰：杜绝子类覆盖方法、注入可变逻辑，从继承链上彻底切断破坏可能性；
- value 和 coder 是 private + final：既不让外部拿到引用，也不允许内部重新赋值指向新数组；
但仅靠 final 还不够——数组元素本身仍可修改。真正兜底的是下一条。
立即学习“Java免费学习笔记（深入）”；
2. 零写方法 + 防御性拷贝：连“内部动手”的机会都不给
String 所有构造方法（如 String(char[])、String(byte[])）都做了一件事：不直接引用传入数组，而是拷贝一份：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
this.value = Arrays.copyOf(value, value.length);
这就意味着：即使你传入一个可变的 char 数组，String 内部持有的是副本，外部修改原数组完全不影响它。同时，String 类里没有任何 public 方法能访问或修改 value 数组内容——没有 setter、没有 setCharAt()、没有暴露数组引用的 getter。私有性 + 无写入口，才是不可变的真正铁壁。
3. 哈希缓存 + 常量池：不可变带来的“性能红利”反向强化设计
源码中这个字段很关键：private int hash; // Default to 0
因为内容永不改变，hashCode() 可以安全缓存一次、复用终身。这不只是优化，更是设计契约：如果 String 可变，哈希值就可能在 HashMap 插入后突变，直接导致键失联、数据丢失。同理，字符串常量池（String Pool）能安全复用对象，也是基于“内容恒定”这一前提。这些机制不是附加功能，而是不可变性倒逼出的、必须存在的配套保障。
4. 安全场景即设计边界：让“不该变”成为语言级约束
看 JDK 中大量 API 的签名：ClassLoader.loadClass(String name)、URL.openConnection(String spec)、System.setProperty(String key, String value)……
这些地方传入的 String，一旦被恶意代码中途篡改（比如把 "jdbc:mysql://prod-db" 改成 "jdbc:mysql://attacker-db"），后果不堪设想。不可变性在这里不是“方便”，而是**安全底线**——它把“参数防篡改”从程序员的责任，上升为 JVM 层面的强制保证。
