string.intern()的哈希表在堆中，是jdk 1.7+的字符串常量池，本质为hashtable，仅存堆中字符串对象的引用；验证是否生效用==比较引用，而非equals。
String.intern() 的哈希表在哪？怎么查它是否生效
字符串常量池在 JDK 1.7+ 就是堆里的一个 Hashtable<stringtableentry></stringtableentry>，不是方法区或永久代里那个“老古董”。它不存字符串对象本身，只存堆中字符串对象的引用——这点直接影响你能不能靠 intern() 真正省内存。
验证是否进池最直接的方式是用 == 比引用，而不是 .equals()：
String s1 = new String("user_123").intern();
String s2 = "user_123";
System.out.println(s1 == s2); // true → 已共享引用
如果返回 false，常见原因有：
-
"user_123"字面量还没被加载（比如写在未执行的分支里），intern()调用时池里确实没有 - 字符串内容含不可见字符（如
\u200b、BOM），导致哈希值不同、查不到 - JVM 启动参数限制了字符串池大小：
-XX:StringTableSize=60013（默认值）太小，哈希冲突高，部分字符串可能被丢弃（不报错，静默失败）
为什么拼接字符串调用 intern() 才有效，而 new String().intern() 常白忙
关键在“对象是否已存在”和“谁先注册”。双引号字面量（如 "user_123"）由 ldc 指令在类加载时自动入池；而 new String("user_123") 先在堆造新对象，再调 intern() ——但此时池里已有字面量对应引用，intern() 只返回池中旧引用，堆对象白建了。
真正节省内存的场景是动态生成的重复字符串，比如从数据库、JSON 或日志里解析出的 key：
String userId = jsonNode.get("user_id").asText(); // 来自外部，非字面量
userId = userId.intern(); // ✅ 此时池里大概率没有，会注册堆中这个对象的引用
这种用法才触发“复用堆对象引用”，避免成千上万个 "user_123" 堆实例。注意以下陷阱：
一款AI工具，主要用于使用 Codex CLI 进行深度网络搜索，适用于需要多源综合分析的复杂查询。当 `web_search`（Brave）返回结果不足，或用户……时使用，适合需要提升相关任务效率的用户。
- 不要对
null调用intern()，直接抛NullPointerException - 避免在循环里无条件
.intern()所有字符串——哪怕内容唯一，也会往哈希表塞冗余条目，拖慢 GC 和查找速度 - 若字符串带时间戳等高频变动后缀（如
"order_20260414155322"），intern()几乎无效，还增加哈希表负担
字符串池大小和 GC 行为怎么影响线上稳定性
字符串池在堆中，但它是 JVM 全局结构，不受单个对象的 GC 周期管理。JDK 1.7+ 后，池本身不会被 Full GC 清理，但其中存储的引用所指向的字符串对象，仍受堆 GC 约束——也就是说：池里存的是弱可达引用，对应堆对象被回收后，池中条目变成 dangling reference，后续查询会重新注册新对象。
真正要盯住的是两个参数：
-
-XX:StringTableSize：哈希表桶数量，默认 60013（质数）。若你有 100 万唯一字符串要 intern，建议设为2000003以上，否则哈希冲突激增，查找退化为链表遍历，CPU 拉高 -
-XX:+PrintStringTableStatistics：加这个参数跑一次压测，JVM 退出时会打印类似StringTable size = 60013, entries = 98432, buckets = 59997, memory used = 32768KB——看entries / size是否接近 1，远高于 1 就该调大StringTableSize
另外，字符串池过大（比如百万级条目）会导致 Metaspace 里的 StringTable 元数据膨胀，虽不直接 OOM，但会挤压其他元数据空间。
什么时候不该用 intern()，哪怕它听起来很省
不是所有重复字符串都适合走池化。以下情况调用 intern() 得不偿失：
- 字符串生命周期极短（如 HTTP 请求头中的
"X-Request-ID"），刚 intern 完就出作用域，池里留着没意义，还占哈希表 slot - 应用使用了字符串缓存框架（如 Caffeine +
Stringkey），自己再 intern 属于双重管理，反而干扰 LRU 策略 - 字符串内容来自用户输入且熵很高（如 Base64 编码的图片片段），重复率低于 0.1%，intern 开销（哈希计算 + 表查找 + 可能扩容）超过内存收益
- 多模块共用同一 JVM，但各模块对字符串语义理解不一致（如
"PENDING"在订单模块表示待支付，在风控模块表示待审核），强行统一引用可能引发逻辑耦合
最易被忽略的一点：JDK 9+ 引入 Compact Strings（byte[] + 编码标识），让单字节字符串（ASCII）内存减半；而 intern() 后的对象仍遵循此优化，但池化本身不改变底层存储格式——所以别指望 intern() 能帮你把 UTF-16 字符串“压缩”成 ASCII 存储。
