Java 中 String 常量池内存溢出如何排查与优化

String 常量池内存溢出，听起来像是个老古董问题，但在实际生产环境中，它依然是个不容忽视的暗礁。说到底，这主要跟JDK版本有关，也跟开发者对String.intern()的“误用”脱不了干系。在JDK 6及更早的版本里，如果String.intern()被高频、无节制地调用，永久代（PermGen）很容易被撑爆。从JDK 7开始，常量池搬到了更宽敞的堆里，JDK 8之后又由元空间（Metaspace）管理，但这并不代表高枕无忧，如果滥用intern()，堆溢出或Metaspace溢出依然可能发生。所以说，排查这类问题，关键不在于猜，而在于日志、监控和代码模式这三者的交叉验证。

如何从OOM日志中捕捉线索？

当服务崩溃时，第一时间要看日志里的关键线索。这需要同时满足两个条件：异常信息必须是ja va.lang.OutOfMemoryError: PermGen space（针对JDK 6）或者ja va.lang.OutOfMemoryError: Metaspace（针对JDK 8+）；同时，堆栈信息中必须出现String.intern(Native Method)，且它的上层紧跟着循环结构或批量处理逻辑。如果这两点都吻合，基本可以锁定方向了。

用jstat观察常量池的使用趋势

如果服务还没宕机只是响应变慢，这时候jstat是个好帮手。针对JDK 6，可以执行jstat -gcpermcapacity ，观察PermCap的使用率，如果它在数分钟内从30%飙升至95%以上且不回落，基本可以断定是intern()泛滥成灾了。对于JDK 8+，则需要执行jstat -gc ，重点关注MCMN（Metaspace容量最小值）、MC（当前容量）和MU（已使用量）。如果这些数值持续上涨，而且GC之后也不释放，就需要高度警惕了。

代码中的高频误用模式

排查到最后，还是要回归代码本身。以下三类高危写法是最常见的“罪魁祸首”：

• 在分页查询中，对每条记录的字段无条件调用rs.getString("status").intern()，这是最经典的错误示范。
• 在日志拼接或SQL构建时，先拼串再调用intern()，比如("UPDATE t SET v=" + value).intern()，这等于把一堆临时对象塞进常量池。
• 从字典表加载枚举值时，未做去重就逐行intern()。比如有10万行数据，但实际上只有5种状态，却硬生生执行了10万次intern()操作。

临时止血与长期修复策略

一旦确认问题，就需要分两步走了。临时缓解的方案主要针对JDK 6：设置JVM参数-XX:PermSize=128m -XX:MaxPermSize=384m，避免启动即满，但注意上限最好不要超过512m，否则GC效率会严重恶化。至于根治方案，其实很简单：禁用循环内的intern()调用。取而代之的是预加载白名单机制——在启动时读取所有合法字符串，去重后逐一intern()，并存为一个缓存用的Map。在运行时，只查缓存，绝不动态生成后入池。这才是真正的一劳永逸。