String.intern()仅对动态生成、高重复且未入池的字符串有效，字面量调用无效；验证需用==而非equals；批量处理须判空、限长、预热，高并发下应缓存优化。

直接用 String.intern() 处理集合里的重复字符串，确实能省内存，但不是所有字符串都适合——关键看来源、重复率和生命周期。

哪些字符串调用 intern() 才真能省空间

只有动态生成、内容高度重复、且尚未入池的字符串，intern() 才起作用。字面量（如 "OK"）本身已在常量池，再调一次只是返回原引用，不新增也不释放。

• ✅ 有效场景：从数据库查出的 status 字段（仅 "PENDING"/"SHIPPED"/"DELIVERED"），每条记录都 new 一个字符串 → 调 .intern() 后，10 万条最多只占 3 个堆对象
• ✅ 有效场景：JSON 解析得到的 userType（如 jsonNode.get("type").asText()），内容来自外部，未被 JVM 预加载 → 入池后可复用
• ❌ 无效场景：new String("hello").intern() —— 字面量 "hello" 已在池中，堆上那个 new 出的对象仍存在，白占内存
• ❌ 无效场景：带时间戳的字符串（如 "order_20260508154022"），几乎无重复 → intern() 只是往哈希表多塞一条，徒增开销

怎么验证 intern 是否生效

不能靠 equals()，得用 == 比较引用。只要两个字符串内容相同、且都经过 intern()（或其中一个是字面量），结果应为 true。

• 示例验证：

  String a = "DELIVERED";
  String b = resultSet.getString("status").intern(); // 假设值为 "DELIVERED"
  System.out.println(a == b); // true → 已共享同一堆对象引用
  

• 若输出 false，常见原因：字符串含不可见字符（如 \u200b）、JVM 参数 -XX:StringTableSize 过小导致哈希冲突丢弃、或该字符串字面量尚未被类加载触发入池

集合批量处理时的安全写法

别在循环里无脑调 str.intern()。null、超长串、唯一串都会带来风险。

• 必须判空：str != null ? str.intern() : null，否则抛 NullPointerException
• 建议加长度限制：str != null && str.length() ，避免把几 MB 的日志行塞进字符串池
• 对已知枚举值，可预热：Arrays.asList("PENDING", "SHIPPED", "DELIVERED").forEach(String::intern)，确保启动时就入池，后续直接命中
• 高并发下慎用：intern() 是同步方法，若每秒调用数万次，可能成为锁瓶颈；可考虑先用 ConcurrentHashMap 缓存映射，再 fallback 到 intern()

它不是享元模式，但能当享元用

String.intern() 本身不是完整享元模式——它不管理对象生命周期、不分离内外状态、也不支持自定义类型。但它复用了享元的核心思想：查表 + 复用 + 不可变前提。

• 适合字段级收敛：比如配置对象中的 serviceId、region、env，都是有限字符串 → 直接 .intern()
• 不适合结构化数据：如 Map tags，需自己实现 TagSet 享元类 + 工厂缓存
• 享元工厂要保证线程安全：用 ConcurrentHashMap 做缓存，computeIfAbsent 保证 get-or-create 原子性