Java 7u6起substring()已改为深拷贝char[]，彻底解决内存泄漏：子串仅占用实际所需内存，原大字符串可及时GC，兼顾内存安全与GC可预测性。
Java 中的 String.substring() 在 Java 7u6 之前存在内存泄漏风险，但自 Java 7 更新后已彻底重构为**真正拷贝底层字符数组**，不再共享原字符串的 char[]。这意味着：切片操作不再“节省内存”，但换来了**内存安全、可预测的 GC 行为和线程安全**——这是高效内存管理的前提。
Java 7+ substring 的核心机制：深拷贝而非共享
在 Java 6 及更早版本中，substring() 仅创建新 String 对象，但复用原字符串的整个 char[]，并仅调整 offset 和 count 字段。若原字符串极大（如读取了 100MB 日志），而只取其中 10 字符子串，该子串仍强引用着全部 100MB 数组，导致无法回收。
Java 7u6 起，substring() 内部调用 Arrays.copyOfRange(value, beginIndex, endIndex)，**真实复制所需范围的字符**，新 String 拥有独立的、最小尺寸的 char[]。这带来三点关键变化：
- 内存占用更精确：子串只占其实际长度所需空间（+对象头开销）
- 原大字符串可被及时 GC，只要无其他引用
- 消除因 substring 链式引用引发的隐蔽内存溢出
高效切片的实践建议（Java 7+）
虽然 substring 已安全，但盲目使用仍可能影响性能。以下为优化要点：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
-
避免在循环中高频调用 substring 处理超长文本：每次调用都触发数组复制（O(n) 时间 + 新对象分配）。若需多次提取相似片段（如解析 CSV 行），优先用
String.indexOf()定位边界，再批量截取；或改用CharBuffer.wrap(charArray).subSequence()（零拷贝，但需确保 char 数组生命周期可控） - 对确定长度的固定模式提取，考虑正则预编译 + Matcher.group()：比反复 substring + trim 更清晰，JIT 优化后性能差距不大，且语义明确
-
极端场景（GB 级文本流处理）不用 String 承载全文：改用
java.nio.CharBuffer、InputStreamReader分块读取，或内存映射文件（MappedByteBuffer），避免一次性加载到堆内存
验证是否发生拷贝：看字节数与对象引用
可通过以下方式确认 substring 行为：
- 用 JOL（Java Object Layout）工具打印对象内存布局：
String big = "x".repeat(1000000); String sub = big.substring(0,5);→sub的char[]长度为 5，非 1000000 - 使用 VisualVM 或 JFR 观察堆内存中
[C（char 数组）实例数与大小分布，substring 后的大数组若无引用，应快速消失 - 反射检查
String.value字段（仅用于调试）：Java 7+ 中sub.value.length == sub.length()
替代方案对比：什么情况下不该用 substring
当目标不是“获取子串值”，而是“标记文本区域”或“延迟提取”，以下方案更优：
- 区间记录（start/end int）：如解析器中保存偏移量，直到真正需要字符串时才调用 substring —— 减少临时对象
- TextBlock（Java 15+ 预览，Java 16+ 正式）：对多行文本字面量更友好，但不改变 substring 语义
- Apache Commons Lang 的 StringUtils.substring()：提供空安全、越界静默等便利，底层仍是 JDK substring，无内存优势
Java 7+ 的 substring 是一次重要的工程权衡：用少量复制开销换取内存模型的简洁与可靠。理解它“已拷贝”的事实，比纠结如何“避免拷贝”更重要。合理设计数据生命周期，比微操单次 substring 调用更能决定长文本处理的效率上限。
