直接查看gc日志和字符串表统计可快速确认string.intern()滥用是否拖慢垃圾回收：若collision接近entry数、ygc耗时突增但晋升量小、internal内存持续膨胀，且代码中存在唯一字符串或循环内无条件调用intern，则大概率是其导致gc效率下降。
直接看 GC 日志和字符串表统计，就能快速确认是不是 String.intern() 滥用拖慢了垃圾回收。
查 GC 日志里有没有“字符串表冲突高”或“老年代晋升异常”
启动时加参数 -XX:+PrintStringTableStatistics，JVM 退出或 Full GC 后会打印类似：
- buckets: 60013, entries: 58241, collisions: 47392 —— collision 接近 entry 数，说明哈希桶严重过载，intern() 查找变慢，GC 线程频繁等待锁
- young gc 耗时突增、但晋升到老年代的对象量不大 —— 可能是 intern 后的字符串引用长期滞留，导致 G1 或 CMS 提前触发混合回收或并发模式失败
- 日志中出现大量
StringTableResize或StringDeduplication相关记录，但实际 dedup 效果差（G1 的 dedup 只处理老年代已升代对象，而 intern 对象多在年轻代就驻留）
用 jstat 和 jcmd 观察字符串表实时压力
执行命令：jstat -gc <pid></pid> 关注 YGC、FGC 频次和耗时；再执行：jcmd <pid> VM.native_memory summary</pid> 查看 Internal 区域是否异常膨胀（StringTable 占用算在这里）。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 如果
YGC次数没变，但每次耗时从 10ms 涨到 50ms+，且jstack显示多个线程阻塞在String.intern(Native Method)，基本是全局字符串表锁争抢 -
jcmd <pid> VM.native_memory summary scale=MB</pid>输出中Internal项持续增长（比如从 20MB → 120MB），而堆总用量未同步飙升，说明 StringTable 自身结构（哈希桶数组）占内存过多
扫描代码里三类高危 intern 调用模式
重点检查以下写法，它们不省内存反而加重 GC 压力：
- 对带时间戳、UUID、用户 ID 等唯一后缀的拼接字符串调用 intern，例如
("order_" + orderId).intern()—— 每次都注册新条目，StringTable 快速膨胀 - 循环内无条件调用
rs.getString("status").intern()，且数据库返回值未去重（10 万行含 200 种状态，却执行了 10 万次 intern） - 用
new String(jsonStr).intern()解析外部数据 —— 先在堆造冗余对象，再入池，临时对象拖慢 Young GC，还可能因 substring 引用大数组导致内存泄漏
验证是否真由 intern 导致 GC 效率下降
临时关闭 intern 行为做对比：
- 把疑似位置的
.intern()注释掉，加日志输出原始字符串哈希码和长度，观察 GC 时间是否回落 - 用
-XX:StringTableSize=262144（质数）扩容哈希表，再压测 —— 如果 collision 数大幅下降、GC 耗时收敛，说明原 size 是瓶颈 - 改用静态映射表替代：如
public static final Map<string string> STATUS_POOL = Map.of("SUCCESS", "SUCCESS", "FAILED", "FAILED");</string>，运行时只查表不调 intern，GC 压力通常明显缓解
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
