string.intern()对低基数字符串特别有效，因其通过常量池复用相同内容对象，将千万级重复字符串实例减至个位数，但仅适用于取值少、重复高、生命周期长的字段，需避免高基数或冗余数组字符串的误用。
用 String.intern() 优化低基数重复字符串（如“男”“女”“北京”“广东”）的堆内存，核心是**让所有相同内容的字符串共享同一个对象实例**，从而大幅减少对象数量和引用开销。但必须谨慎使用，否则可能引发性能下降或元空间溢出。
为什么 intern() 对低基数文本特别有效
低基数意味着取值种类少（比如性别只有 2–3 种，省份约 34 种），但实例数量极大（如千万级用户记录）。若每条记录都 new 一个新 String，即使内容相同，也会在堆上创建独立对象，浪费大量内存（每个 String 对象至少 40+ 字节开销 + char[] 数组）。而 intern() 会将字符串首次放入 JVM 运行时常量池（JDK 7+ 后在堆中），后续相同内容调用直接返回池中已有引用，实现对象复用。
正确使用的典型模式
关键不是“所有字符串都 intern”，而是**只对明确已知低基数、高重复、生命周期长的字段做显式 intern**。常见做法：
-
读取时立即 intern：解析 CSV/JSON/DB 结果时，对“性别”“省份”等字段调用
str.intern()，而不是等后续逻辑再处理 -
配合不可变封装类使用：定义
Gender.MALE、Province.BEIJING等枚举或静态常量，从源头避免字符串构造；若必须用字符串（如兼容旧协议），则在 setter 或 builder 中强制 intern -
避免在循环内无条件 intern：不要写
for (String s : list) s.intern();—— 即使 s 已是常量池中对象，intern() 仍需查表，徒增开销
必须避开的坑
intern() 不是银弹，错误使用反而伤性能：
-
不要 intern 高基数或随机字符串（如用户名、订单号）：会导致常量池膨胀，GC 压力大，甚至
java.lang.OutOfMemoryError: Metaspace（JDK 8）或堆 OOM（JDK 7+） -
注意字符串来源：由
substring()、concat()或StringBuilder.toString()生成的字符串，底层 char[] 可能远大于实际内容（尤其 JDK 7u6 以前），intern 后仍保留冗余数组；建议先new String(str)再 intern（JDK 7+ 可省略） - 并发安全但有锁开销：intern 是本地方法，内部有全局锁（JDK 8 中为 SymbolTable 锁），高频调用会成为瓶颈；可考虑预热：启动时把所有可能取值提前 intern 一遍
效果验证与替代方案
优化前后可用 jmap -histo 或 VisualVM 对比 String 实例数和总占用。典型场景下，性别字段 intern 后 String 对象数可从千万级降到个位数。
更现代、可控的替代方式包括：
- Enum + 自定义 toString()：最安全，类型安全，零 GC 开销
-
WeakHashMap 缓存：手动维护
WeakHashMap<string string></string>，避免强引用阻塞 GC，适合需要动态加载的场景 -
字符串飞重（String Deduplication）：JDK 8u20+ 开启
-XX:+UseStringDeduplication（仅 G1 GC），JVM 自动合并重复字符串，无需代码改动，适合无法修改源码的场景
不复杂但容易忽略：真正节省内存的是减少对象数量，而不是单个字符串变小；选对字段、控制范围、配合监控，intern 才是利器。
