jdk 9+ 中 string 的 value 字段改为 byte[] + coder 以节省内存，latin-1 编码占 1 字节，utf16 占 2 字节；反射修改失效、substring 不再共享数组、intern() 控制常量池引用，不可变性源于封装而非仅 final 修饰。
![什么是java中的字符串不可变性_深入源码看char[]与byte[]的封装](https://img.php.cn/upload/article/000/969/633/177088989292918.jpeg)
String 的 value 字段在 JDK 9+ 已不是 char[]
JDK 9 起，String 内部存储从 char[] value 改为 byte[] value + byte coder，这是为了节省内存（Latin-1 字符只占 1 字节）。如果你在源码里找 char[]，会发现它已不存在——除非你用的是 JDK 8 或更早版本。
常见错误现象：String 反射修改 value 在 JDK 9+ 失效，甚至抛 NoSuchFieldException；或修改后字符串内容没变，是因为 coder 解码逻辑绕过了你的字节篡改。
- 使用场景：调试、安全审计、或老项目迁移时误以为
value还是char[] - 参数差异：
coder == 0表示 LATIN1 编码（byte[]每字节存一个字符），coder == 1表示 UTF16（此时byte[]实际是两字节一组） - 性能影响：对纯 ASCII 字符串，内存占用直接减半；但频繁调用
String.toLowerCase()等方法时，可能触发隐式解码/编码开销
不可变性 ≠ 字段 final，而是靠封装和无对外引用保证
String 的 value 字段确实是 final，但这只是表象。真正让字符串“不可变”的，是它从不对外暴露可修改的引用，且所有构造、截取、拼接操作都返回新对象。
常见错误现象：有人用反射把 value 设为非 final 并修改内容，结果发现 "abc".hashCode() 还是旧值——因为 hash 字段也是 final 且缓存在首次调用时，不会重算。
立即学习“Java免费学习笔记（深入）”；
- 使用场景：写工具类试图“复用”字符串底层数组（比如解析大日志时避免反复 new String）
- 容易踩的坑：
String(byte[])构造函数会拷贝数组，但String(byte[], int, int)在 JDK 7u6 之后也拷贝了；想绕过拷贝只能用Unsafe或String(byte[], int, int, Charset)配合自定义 Charset（不推荐） - 兼容性影响：JDK 7u6 是分水岭，之前部分构造函数共享底层数组，现在全拷贝，安全性提升但内存略增
substring() 在 JDK 7u6 后不再共享底层数组
老书里常说 substring() “可能导致内存泄漏”，那是指 JDK 6 及之前——它返回的新 String 直接引用原 value 数组，哪怕只取一个字符，整个大数组也 GC 不掉。JDK 7u6 起，substring() 总是新建 byte[]（或 char[]），彻底切断引用。
常见错误现象：升级 JDK 后堆内存占用反而上升，尤其处理大量短子串时；或者依赖旧版“共享数组”做零拷贝切片的代码行为突变。
- 使用场景：日志行解析、协议报文拆包、CSV 字段提取
- 性能影响：小字符串切片变慢（多了数组拷贝），但大字符串切片更安全；可用
CharBuffer.wrap(array, start, len)替代，它真共享且可读写 - 注意：
String.substring(int)和String.substring(int, int)行为一致，都拷贝，别指望后者更“轻量”
intern() 不是“让字符串可变”，而是控制字符串常量池引用
String.intern() 的作用，是把字符串实例注册到 JVM 运行时常量池，并返回池中已有或新加入的引用。它不改变原字符串内容，也不让字符串变得“可变”——只是多了一条指向它的路径。
常见错误现象：调用 new String("abc").intern() 后以为原对象被替换了；或在 CMS GC 下频繁调用 intern() 导致常量池撑爆，抛 OutOfMemoryError: Metaspace。
- 使用场景：去重大量重复字符串（如 JSON key、数据库字段名）、减少内存碎片
- 参数差异：JDK 7+ 常量池移到堆内存，
-XX:MaxMetaspaceSize不再限制它；但-XX:StringTableSize影响哈希桶数量，默认 60013，冲突多时需调大 - 容易忽略的点：
intern()是本地方法，有锁，高并发下调用会成为瓶颈；建议批量预热或用ConcurrentHashMap<string string></string>模拟
真正难的不是看懂 value 是 byte[] 还是 char[]，而是理解“不可变”是设计契约，不是语言特性——只要你不通过反射、Unsafe 或 JNI 打破封装，JVM 就能放心做优化，比如字符串压缩、编译期折叠、甚至栈上分配。
