JDK 6 的 substring 共享原字符串 char[]，导致内存泄漏；JDK 7u6+ 改为复制新数组，彻底解耦。可通过检查 value.length 是否等于原数组长度判断是否安全，兼容方案是 new String(s.substring(start, end))。
substring 在 JDK 6 和 JDK 7+ 的实现差异
旧版本（JDK 6）的 substring 不复制字符数组，而是共享原 String 的 value 数组和偏移量；新版本（JDK 7u6+）则强制拷贝子串所需字符到新数组。这意味着：如果你从一个超大字符串中用 substring 取出几个字，JDK 6 下那几个字会一直 hold 住整个原始大数组，导致内存无法回收。
常见错误现象：OutOfMemoryError 出现在大量调用 substring 处理日志、JSON 或文件内容后，堆里全是没被释放的 char[]。
- JDK 6：调用
substring后，原字符串即使被置为null，其底层char[]仍被子串引用 - JDK 7u6 起：每次
substring都新建char[]，子串与原串彻底解耦 - 可通过
string.substring(0, 1).intern()触发常量池驻留，在 JDK 6 中进一步加剧泄漏（因 intern 也引用原数组）
如何判断当前 substring 是否安全
不能只看 JDK 版本号——有些 Android Runtime（如 ART 5.0–7.x）或老版 OpenJDK 衍生环境仍沿用类似 JDK 6 的实现。最直接的办法是看对象图：
- 用 JFR 或 MAT 打开 heap dump，查某个小
String实例的value字段是否指向一个远大于自身长度的char[] - 在代码中加断点，观察
string.substring(10, 11)返回对象的value.length是否等于原字符串的value.length - 若相等，说明仍在共享底层数组，属于“不安全”行为
注意：String.valueOf(char[])、new String(char[]) 均无此风险，它们总是新建数组。
立即学习“Java免费学习笔记（深入）”；
替代方案：显式触发拷贝（兼容所有 JDK）
当无法升级 JDK 或需确保行为一致时，手动“破除共享”是最稳妥的做法。核心就是让 JVM 创建真正独立的字符数组。
- 写法：
new String(s.substring(start, end))—— 这会强制拷贝底层char[]，无论 JDK 版本 - 性能影响：多一次数组拷贝，对短字符串可忽略；但高频截取长文本时要注意，建议配合
StringBuilder批量处理 - 不要用
s.substring(start, end).toString()，它只是返回自身，不解决共享问题 - 如果已知输入来自
StringBuilder.toString()，可改用sb.subSequence(start, end).toString()，因为subSequence返回的是CharSequence，且现代 JDK 对它的实现不共享数组
容易被忽略的隐式 substring 场景
很多开发者只盯着显式的 substring 调用，却忽略了框架或工具类内部的“黑盒截取”。这些地方同样可能引发泄漏：
-
StringTokenizer在 JDK 6 下构造时会缓存原始字符串，后续nextToken()返回的仍是substring结果 - Apache Commons Lang 的
StringUtils.substring底层仍调用String.substring，不改变行为 - JSON 解析器（如 Jackson 2.9 以前）在解析字符串字段时，若启用
JsonParser.Feature.USE_THREAD_LOCAL_FOR_BUFFER_RECYCLING，可能复用缓冲区并间接保留大字符串引用 - 日志框架（如 Log4j 1.x）格式化模板时，若模板中含
%m且日志内容来自大字符串截取，可能把整个原始对象带入 MDC 或异步队列
这类问题往往在线上压测或长时间运行后才暴露，排查时要重点检查 GC 日志里的 char[] 占比和存活时间。
