stringtable是哈希表，不自动去重，仅通过字面量加载或显式调用intern()才插入条目；intern()在jdk7+存引用而非复制对象，滥用会导致哈希冲突、内存泄漏及性能下降。
StringTable 本身不自动去重，intern() 是显式入池动作
很多人误以为 StringTable 像 GC 那样“自动扫描并合并重复字符串”，其实不是。它只是一个哈希表（Hashtable），只在你调用 String.intern() 或字面量加载时才插入条目。没有调用 intern() 的字符串，哪怕内容完全一样，也会在堆里各自占一份 byte[]（JDK9+）或 char[]（JDK8-）。所以“去重”不是后台服务，而是你主动触发的行为。
常见错误现象：String s1 = new String("hello"); String s2 = new String("hello"); System.out.println(s1 == s2); // false —— 这两个对象没进 StringTable，也不共享底层数组。
- 只有
"hello"字面量、"hello".intern()、或通过类加载器解析的常量才会进入StringTable -
intern()在 JDK7+ 是“存引用”，不是“复制对象”，所以开销比 JDK6 小得多 - 大量调用
intern()但StringTableSize过小，会引发严重哈希冲突，链表变长，intern()耗时飙升（实测从纳秒级涨到微秒甚至毫秒级）
调整 -XX:StringTableSize 避免哈希桶过载
StringTable 默认大小在 JDK8 是 60013，看似够用，但如果你的应用每秒解析数万条日志、JSON 或 CSV 行，且每行含多个重复字段（如 status="OK"、type="user"），intern() 频繁命中同一桶，性能就会断崖下跌。
使用 jcmd <pid> VM.native_memory summary</pid> 或 jstat -gc <pid></pid> 观察 StringTable 使用率并不直接可见，但可通过 -XX:+PrintStringTableStatistics 启动后看输出中的 “buckets: X, entries: Y, collisions: Z” —— 如果 collisions 接近或超过 entries，说明桶太少。
- 建议初始值设为预期唯一字符串数的 2–3 倍，例如预估有 50 万个不同字符串，就设
-XX:StringTableSize=131072（2^17） - 不能设得过大：每个桶占固定内存（约 8–16 字节指针），1M 桶 ≈ 8–16MB 内存，纯浪费
- JDK8 要求最小值是 1009；JDK11+ 支持动态扩容，但首次设置仍影响启动时分配
G1 的 StringDeduplication 和 StringTable 是两套机制
别混淆：G1 的 -XX:+UseStringDeduplication 是 GC 级别的后台线程行为，它扫描老年代中已升代的 String 对象，对它们的底层 byte[] 做内容比对，相同则让多个 String 共享一个数组。这不需要你改代码，但有硬性前提：
- 仅作用于老年代对象（年轻代新字符串不处理）
- 要求字符串已升代，且内容完全一致（包括编码标记，
coder字段也得一样） - 依赖 G1 的并发标记周期，不是实时发生；ZGC 不支持该参数，它用自己的并发去重逻辑
- 开启后 GC 日志会出现
String Deduplication:统计行，可验证是否生效
而 StringTable + intern() 是应用层控制，立即生效、确定性强，但要你主动加调用。两者可共存，但目标不同：前者省 GC 压力，后者省堆内对象数量和引用关系。
真实场景下怎么选：读配置/日志 vs. 用户输入
对稳定、有限、高重复的字符串集合（如 HTTP 状态码、枚举值、配置项 key），优先用 intern() + 调大 StringTableSize。这是最可控、效果最稳的方式。
对不可控、高频、短生命周期的字符串（如用户搜索词、临时 token），别盲目 intern() —— 它们很快被回收，但 StringTable 条目不会自动清理（除非 GC 触发 StringTable 清理，且对象无强引用），反而造成泄漏风险。
- 典型反例：循环里写
line.trim().toLowerCase().intern()，结果把所有用户输入都塞进StringTable，OOM 前兆 - 安全做法：先用
Set<string></string>缓存已知枚举值，只对白名单字符串调用intern() - 如果用的是 G1 且字符串多为老年代驻留，可以开
-XX:+UseStringDeduplication作为兜底，但别指望它解决年轻代爆炸问题
最易被忽略的一点：JDK9+ 的 String 底层是 byte[] + coder，两个内容相同的字符串，若一个用 Latin-1 编码（全 ASCII），另一个误触发 UTF-16（比如中间插了个 \u0000），intern() 或 G1 去重都会失败——它们比较的是字节数组内容，不是逻辑等价。
