string常量池是需主动设计的优化杠杆，非自动省内存开关；jdk7+移至堆中可gc，适合长期存活、高度重复、用作哈希key的字符串；避免热点路径无条件intern，优先预加载和字面量使用。
Java 中 String 常量池在大型项目里不是“自动省内存”的开关，而是需要配合代码习惯和运行特征主动设计的优化杠杆。它真正起效的前提是：重复内容多、生命周期长、引用稳定。
常量池位置与 GC 行为必须清楚
JDK 7 起字符串常量池已移到堆内存中，和普通对象一样可被垃圾回收——这点直接影响缓存策略是否安全：
- JDK 6 及以前：常量池在永久代，大小固定、不参与 GC，intern() 过的字符串一旦进入就几乎永驻，容易撑爆 PermGen 导致 OOM
- JDK 7/8/9+：常量池在堆中，没有强引用时可被回收，但频繁 intern 短期字符串仍可能推高堆压力或触发额外 GC
- 注意：元空间（Metaspace）不存字符串，常量池始终在堆里，别误配 -XX:MaxMetaspaceSize 来“解决”字符串内存问题
哪些字符串值得进常量池？看三个硬指标
不是所有重复字符串都适合 intern，关键看是否同时满足：
- 长期存活：作为配置项 key（如 "database.url"）、协议标识（"HTTP/1.1"）、枚举字面量（"PENDING", "COMPLETED"）等，在整个应用生命周期内持续存在
- 内容高度重复：比如日志级别（"INFO"/"ERROR"）、状态码（"200"/"404"）、城市名（"Beijing"/"Shanghai"）在千万级请求中反复出现
- 用作哈希结构 key：在 HashMap / ConcurrentHashMap 中高频作为键使用，复用能减少 equals() 调用和哈希冲突
反之，用户输入、URL 路径拼接、JSON 字段名临时生成、循环内 StringBuilder.toString() 结果——这些绝不建议调用 intern()，徒增拷贝开销且无实际收益。
避免常量池成为性能瓶颈的实操要点
常量池底层是哈希表，默认容量 60013（JDK 8+），但高并发大量 intern 可能引发 hash 冲突和锁竞争：
- 若确认需大规模 intern（如解析百万级静态词典），可通过 -XX:StringTableSize=131072 扩容哈希桶，减少链表深度
- 避免在热点路径（如每请求都调用的 filter 或 interceptor）中无条件 intern；优先用预加载方式，启动时批量 intern 已知固定值
- 验证是否生效：用 s1 == s2 判断引用一致，比 .equals() 更直接；配合 JVM 参数 -XX:+PrintStringDeduplicationStatistics 查看去重效果（JDK 8u20+）
- 警惕 new String("x").intern() 的冗余创建：先堆上建对象再塞池里，不如直接用字面量 "x" —— 多一步 new 就多一次内存分配
比 intern 更轻量的优化习惯
真正节省内存的主力，往往来自写法克制：
- 用字面量代替 new String("abc")：前者只走常量池，后者必造堆对象
- 拼接尽量用编译期优化：如 "a" + "b" + "c" → "abc"（字节码中已合并），而 s1 + s2 必走 StringBuilder
- 读取外部数据（如配置、DB）后，对确定重复的字段做一次 intern，而非每次 get 后都 intern
- JDK 9+ 自动启用紧凑字符串（ASCII 占 1 字节），无需改动代码，但要注意：含中文、emoji 的字符串仍用 2 字节/字符，别误判整体内存降幅
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
