为了节省内存：jdk 9 将 string 底层从 char[] 改为 byte[]，配合 coder 字段区分 latin-1（1 字节/字符）和 utf-16（2 字节/字符），使纯 ascii/latin-1 字符串内存占用减少近一半。
String 内部从 char[] 变成 byte[] 是为了什么
不是为了“兼容旧代码”或“语法糖”，而是直击内存浪费：JDK 8 及之前，String 强制用 char[] 存储，每个 char 占 2 字节。哪怕字符串全是 'a''1''_' 这类 ASCII 字符（完全可用 1 字节表示），也照扣 2 字节不误。
Oracle 实测发现，80–90% 的字符串只含 Latin-1 字符（U+0000 到 U+00FF）。把这部分全压成 1 字节存储，堆内存直接少掉近一半的字符串开销——尤其在微服务、日志密集、JSON 解析多的场景下，效果肉眼可见。
coder 字段怎么决定用 Latin-1 还是 UTF-16
coder 是个 byte 类型字段，值只有两个：LATIN1（0）或 UTF16（1）。它不参与字符串内容比较，只在构造时由 JVM 内部逻辑一次性判定：
- 遍历所有字符，调用类似
Character.isLatin1(char)的判断（实际是codePoint >>> 8 == 0） - 只要有一个字符超出 Latin-1 范围（比如中文、emoji、希腊字母），就 fallback 到
UTF16编码，整个value数组按 2 字节/字符存 - 判定发生在构造阶段（
new String(...)、字面量、String.valueOf(...)等），之后coder不再改变
注意："abc".substring(1) 返回的新字符串仍保持原 coder，不会重新检测子串内容。
为什么说 COMPACT_STRINGS 是默认开启且不可关闭的
这个特性在 JDK 9+ 是硬编码启用的，没有 JVM 参数能关掉它。你看到的 String.COMPACT_STRINGS 是一个 static final boolean 常量，值恒为 true（JDK 源码里直接写死），它只是供反射或调试时确认用的，并非开关。
容易踩的坑：
- 别在启动参数里加
-XX:-CompactStrings—— 这个选项早在 JDK 9 就被移除了，加了会报Unrecognized VM option - 某些老工具（如特定版本 JOL 或 MAT 插件）可能还按
char[]解析String对象大小，导致内存估算偏高，需升级到支持 JDK 9+ 结构的版本 -
String.getBytes(StandardCharsets.UTF_8)这类方法不受影响，它们始终返回新数组；但String.length()和charAt()在 Latin-1 字符串上实际走的是StringLatin1静态工具类，比以前略快一点
Latin-1 字符串的内存节省能精确算出来吗
可以，而且很简单：
- JDK 8：
"Hello"→ 5 × 2 字节 = 10 字节（仅char[]数据，不含对象头、对齐等） - JDK 9+：
"Hello"→ 5 × 1 字节 + 1 字节coder= 6 字节（value是byte[5]，coder单独占 1 字节） - 中文字符串如
"你好"：两种 JDK 都是 4 字节（2 字符 × 2 字节），因为必须用 UTF-16 编码
真正省空间的是混合场景：比如一个 Spring Boot 应用里大量 Map<string object></string> 的 key 是 "id""status""user_name" 这类纯 ASCII 字段名——这些字符串集体瘦身，GC 压力就下来了。但如果你的应用主跑日志分析或全文检索，字符串本身含大量 Unicode，那收益就非常有限。
