string.intern()操作的是运行时常量池，jdk 7+后该池位于堆内存中；它通过哈希表（stringtable）实现，性能受-xx:stringtablesize影响，滥用易引发full gc或查找退化。
String.intern()到底在操作哪块内存
它操作的是**运行时常量池（Runtime Constant Pool）**，不是编译期的.class常量池，也不是堆外内存。JDK 7+后，这个池被移到了堆内存里，所以intern()返回的对象和普通new String("abc")创建的字符串一样，GC可回收——但前提是没其他强引用指向它。
常见错误现象：String s = new String("hello").intern();看似“入池”，但若字面量"hello"已存在（比如代码里写过"hello"），intern()直接返回池中已有引用，s就和字面量指向同一对象；否则才把当前字符串对象注册进池并返回它。
- 使用场景：大量重复字符串（如解析日志中的状态码、HTTP方法名、枚举标识）需去重且后续频繁比较时，用
intern()换==提速 - 注意：仅当字符串内容高度重复、生命周期长、且比较频次远高于构造频次时才值得用
- JDK 6中池在永久代，容易OOM；JDK 7+移至堆，但滥用仍会撑大老年代，触发Full GC
为什么String.intern()有时比equals()还慢
因为intern()本质是哈希查找 + 可能的同步 + 对象注册。每次调用都要查常量池哈希表，未命中还要加锁、复制字符数组、插入表项——这比一次equals()的逐字符比对开销大得多，尤其字符串很短（如2~5字符）时。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 不要对随机生成或唯一性高的字符串（如UUID、时间戳拼接串）调用
intern() - 避免在循环内无条件调用：
for (String s : list) { s.intern(); }——哪怕99%的字符串都已存在池中，哈希查找本身就有成本 - 如果只是想加速相等判断，优先考虑预热：确保字面量先出现（如
static final String GET = "GET";），再让待比较字符串intern()，才能稳定落到==分支
String.intern()和-XX:StringTableSize参数的关系
intern()底层依赖一个固定大小的哈希表（StringTable），默认容量是1009（质数）。当大量不同字符串涌入时，哈希冲突加剧，查找/插入退化为链表遍历，性能断崖下跌。
常见错误现象：应用启动后一段时间内intern()耗时稳定在微秒级，某天日志字段突增新值类型，随后监控显示String.intern()平均耗时跳到毫秒级，CPU在StringTable::lookup附近打满。
- 可通过
-XX:+PrintStringTableStatistics查看当前桶数量、平均链长、最大链长 - 扩容需重启JVM，用
-XX:StringTableSize=65536这类2的幂次+1的质数（如65537）更稳妥 - 注意：增大
StringTableSize会多占堆内存（每个桶是个指针，64位下8字节），65537个桶≈512KB，别盲目设到百万级
替代intern()的更可控方案
用ConcurrentHashMap<string string></string>手动维护一个“字符串规范器”更透明、可监控、易清理。
示例逻辑：
private static final ConcurrentHashMap<String, String> CANONICAL_MAP = new ConcurrentHashMap<>();
public static String canonicalize(String s) {
if (s == null) return null;
return CANONICAL_MAP.computeIfAbsent(s, k -> k);
}
优势在于：
- 可精确控制生命周期：
CANONICAL_MAP能被WeakReference包裹，或按LRU淘汰 - 避免JVM全局StringTable锁竞争，高并发下吞吐更稳
- 错误排查直接看map大小、命中率，不用猜JVM参数是否合理
- 兼容所有JDK版本，不受
intern()语义变更影响（如JDK 7前后行为差异）
真正难的不是调不调intern()，而是确认字符串重复模式是否稳定、是否值得用全局共享状态去换那点比较开销——多数时候，一个带缓存的ConcurrentHashMap比赌JVM实现细节更靠谱。
