防止长字符串拼接引发内存溢出，关键是从拼接前设防：预估容量并复用StringBuilder、禁用日志隐式拼接、分批处理超长数据流、慎用intern()。
防止长字符串拼接引发内存溢出，关键不是等报错再处理，而是从拼接行为发生前就设防——重点在“控制对象生命周期”和“规避隐式开销”。
拼接前预估容量并复用 StringBuilder 实例
不预设容量的 StringBuilder 在扩容时会按 1.5 倍规则复制数组，高频扩容叠加大量数据极易触发 GC 压力甚至 OOM。尤其当拼接目标长度可预估（如日志模板、SQL 拼装、JSON 构建）时，应主动设置初始容量。
- 估算最终长度（例如：字段名 + 分隔符 + 值长度总和），乘以 1.2 留出余量，传入 StringBuilder 构造函数
- 避免在循环内 new StringBuilder()；应在方法入口或作用域外创建，循环中只调用 append()
- 拼接完成后及时调用 toString() 获取结果，让 StringBuilder 实例可被快速回收（内部 char[] 不再强引用）
禁用日志与调试中的隐式拼接
哪怕日志级别设为 ERROR，log.info("id=" + id + ", name=" + name) 这类写法仍会强制执行所有字符串拼接，生成中间 String 对象——这是最隐蔽的 OOM 温床。
- 统一改用 SLF4J 占位符格式：log.info("id={}, name={}", id, name)，参数仅在日志启用时求值
- 单元测试或调试中打印对象时，避免直接拼接 toString() 结果；可用 Objects.toString(obj, "null") 或自定义精简输出
- 禁止在 Lambda 表达式或 Stream 中使用 + 拼接作为 map 参数（如 .map(s -> "prefix" + s)），改用 String.format 或 StringBuilder 匿名复用
超长数据流必须分批处理
当字符串来源是文件读取、数据库游标、HTTP 响应体或 LLM 流式输出时，全量加载到内存再拼接等于主动申请 OOM。
立即学习“Java免费学习笔记（深入）”；
- 用 BufferedReader.readLine() 或 Scanner.nextLine() 逐行处理，每行拼入 StringBuilder 后立即写入 FileWriter / ByteArrayOutputStream / ServletOutputStream
- 对分页查询结果，每页拼接后 flush 到临时文件或缓冲区，不累积全部内容
- 若需最终合并，优先走磁盘归并（如 Files.write + Files.readString 分段读），而非堆内拼接
警惕 intern() 和常量池滥用
String.intern() 并非“省内存神器”，它把字符串塞进 JVM 全局常量池（Java 7+ 在堆中，但仍受 MaxMetaspaceSize 限制），且无法被 GC 回收——大量动态生成字符串调用 intern() 是典型的内存泄漏路径。
- 仅对已知有限、稳定、重复率高的字面量（如协议码、状态枚举名）考虑 intern()
- 禁止对用户输入、日志消息、JSON 字段值等不可控字符串调用 intern()
- 可通过 jstat -gc <pid> 观察 Metaspace 使用趋势，配合 MAT 分析常量池占用
