java String 为何引发内存泄漏

在 Java 中，String 本身不会“主动”造成内存泄漏，但由于 Java 的设计和历史实现（尤其是 JDK 6 及以前），如果使用不当，String 很容易成为内存泄漏的“帮凶”甚至直接原因。

下面从原理到常见场景系统说明。

一、为什么大家常说 “String 引发内存泄漏”

核心原因有三点：

1. String 底层使用 char[]（或 byte[]）
2. String 存在常量池（String Pool）
3. substring / intern 等历史实现问题

二、典型内存泄漏场景

1️⃣ JDK 6 及以前：substring() 导致的内存泄漏（最经典）

示例代码

String big = readBigFile(); // 假设 10MB
String small = big.substring(0, 10);

JDK 6 的实现问题

// JDK 6 内部
String {
    char value[];
    int offset;
    int count;
}

• small 和 big 共享同一个 char[]
• 即使你只想要 10 个字符
• 10MB 的 char[] 无法被 GC

✅ 后果：
只要 small 还活着，big 的整个数组都无法释放

解决方案（JDK 6）

small = new String(small);

或

small = small.intern();

✅ JDK 7+ 已修复

• substring() 会创建新的 char[]

2️⃣ String.intern() 使用不当（常量池泄漏）

intern 的作用

String s = new String("abc").intern();

• 把字符串放入 永久代 / 元空间（Metaspace）
• 常量池中的 String 不会轻易被 GC

危险用法

for (...) {
    String key = readFromUser(); // 用户输入
    key.intern(); // ❌ 无限增长
}

✅ 后果：

• 常量池无限膨胀
• JDK 6：PermGen OOM
• JDK 7+：Metaspace OOM

⚠️ 不要用 intern 存动态、不可控字符串

3️⃣ 静态集合持有 String（最常见“业务级泄漏”）

public static Map<String, String> cache = new HashMap<>();

cache.put(bigString, bigString);

只要 cache 不清理：

• String 永远可达
• GC 无法回收

✅ 解决方案：

• 使用 WeakHashMap
• 设置 TTL / LRU 缓存

4️⃣ 日志 / 异常中保存大 String

catch (Exception e) {
    errorLog.put(e.getMessage()); // 大字符串
}

• 异常信息可能包含完整 SQL、报文
• 被日志系统长期持有

5️⃣ 编码转换产生临时大 String

new String(bytes, "UTF-8");

• 一次解析几十 MB 报文
• 未及时处理或释放引用

三、JDK 版本差异总结

四、如何避免 String 相关内存泄漏

✅ 建议做法：

1. 不滥用 intern()
2. 不长期持有大 String
3. 缓存使用 WeakReference
4. 日志避免打印大对象
5. 使用流式处理（不全量读入 String）

五、一句话总结

String 本身不会泄漏，但“长期引用 + 共享数组 + 常量池”会让它成为内存杀手。

如果你有具体场景（如缓存、Netty、日志、JVM 版本），我可以帮你精准分析。