java中string的不可变性是精密设计，确保哈希缓存可靠、常量池可复用、多线程共享安全；它提升map查找效率、防止内存泄漏、保障敏感路径安全，并要求拼接等操作使用stringbuilder避免频繁对象创建。
Java中String的不可变性不是限制，而是精密设计——它让哈希缓存可信赖、让字符串常量池能复用、让多线程共享无需同步。这种设计直接决定了日常开发中内存是否浪费、Map查找是否高效、敏感路径是否安全。
哈希值缓存：一次计算，终身复用
String类内部有一个private int hash字段，默认为0。首次调用hashCode()时，JVM会按公式（如∑ charAt(i) × 31n−1−i）计算并写入该字段；之后再调用，直接返回缓存值。
- 作为HashMap的key时，每次put/get都要计算hash，不可变性确保这个开销只发生一次
- 若String可变，每次调用hashCode()都得重新遍历字符数组，性能下降明显（尤其长字符串）
- 注意：反射强行修改value数组会破坏缓存一致性，但属非法操作，不具工程意义
字符串常量池：复用靠的是“不变”，不是“省事”
字面量如"abc"在编译期就进入常量池；运行期调用intern()也可手动驻留。但前提是内容不能被中途改写。
-
String a = "hello"; String b = "hello";→a == b为true，因指向同一池中对象 - 若String可变，a改了内容，b也会“跟着变”，池就失去意义，甚至引发逻辑错乱
- new String("hello")不进池（除非显式intern），但它的不可变性仍保障自身状态稳定
内存布局演进：从char[]到byte[]+coder，不变的是语义
JDK 9起，String底层由char[]改为byte[] + coder（Latin1或UTF-16），目的是压缩纯ASCII字符串内存占用，但不可变性约束没变。
- value字段仍是final，coder字段也是final，组合起来仍保证字符序列不可更改
- substring等操作不再共享底层数组（JDK 7u40后优化），避免大字符串长期持有所致的内存泄漏
- 所有看似“修改”的方法（concat、replace、toUpperCase等）都返回新String对象，原对象毫发无损
实战避坑：你以为在改String，其实是在造对象
频繁拼接字符串时，str += "x"或str = str + "x"会在循环中不断创建新对象，旧对象等待GC，容易触发Minor GC。
- 大量拼接用StringBuilder（单线程）或StringBuffer（多线程），它们内部用可变char[]，避免重复分配
- 构造完再转String：用
sb.toString()，得到的仍是不可变对象，安全交付给其他模块 - 做Key或配置项时，放心用String——它的不可变性天然屏蔽了并发修改和意外篡改风险
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
