String不可变性由final类、final字段、私有构造和无修改方法共同实现；其优势包括线程安全、HashMap可靠key、JVM优化及API契约稳定。

String对象的不可变性（Immutability）不是语法限制，而是Java在设计层面通过final类、final字段、私有化构造与无修改方法共同实现的语义约束。它的优势不仅在于线程安全和缓存友好，更深层体现在JVM优化、内存效率与API契约稳定性上。

底层如何保证不可变？

Java中String的不可变性由四层机制协同保障：

• 类被声明为final：无法被继承，杜绝子类覆盖方法或引入可变状态
• 内部字符数组char[]（JDK 8及之前）或byte[]（JDK 9+）被声明为final：引用不可重定向，且数组本身不对外暴露（private + 无setter）
• 所有构造方法均拷贝入参数据：即使传入外部char[]，String内部也新建副本，切断外部修改影响
• 所有公开方法（如substring、toLowerCase、concat）均返回新String对象：不修改原对象，符合“无副作用”原则

字符串常量池（String Pool）依赖不可变性

字符串常量池是JVM方法区中的共享区域，用于复用字面量字符串。若String可变，一个引用修改内容将意外污染所有共享该实例的代码：

• 编译期字面量如"hello"自动入池；运行时调用String.intern()可手动入池
• 只有不可变，才能确保池中对象一旦创建就始终代表同一值，使==比较在特定场景下安全有效
• 若String可变，s1 == s2为true时，s1.toUpperCase()会悄然改变s2的内容——这将彻底破坏契约

不可变性带来的核心优势

这些优势不是理论推演，而是直接影响性能、安全与开发体验：

• 天然线程安全：无需同步，多线程可自由共享同一String实例，避免锁开销与死锁风险
• 可作为HashMap等集合的可靠key：hashCode在首次调用时缓存（JDK 7+），因内容永不变化，哈希值恒定，不会导致散列表错位
• 支持JVM深度优化：如字符串拼接的JIT内联、常量折叠（"a"+"b"直接编译为"ab"）、逃逸分析后栈上分配
• 简化API设计与使用逻辑：调用方无需担心传入的String被意外修改，降低防御性拷贝成本

注意：不可变 ≠ 不可操作

常见误解是“String不能改变”，实际是“不能改变自身”。每次操作都生成新对象：

• str.concat("x") 返回新String，原str不变
• str.substring(1) 在JDK 7u6前曾共享底层数组（存在内存泄漏隐患），之后版本已改为复制，彻底隔离
• 频繁拼接应改用StringBuilder，避免大量临时对象引发GC压力