StringBuilder 本身不支持嵌套，所谓“多层嵌套”实为误用：频繁新建实例或未及时释放导致char数组堆积引发OOM；正确做法是复用、清空、必要时trimToSize或改用流式写出。
这个问题其实不是“多层嵌套 StringBuilder”导致的，而是对 StringBuilder 的使用方式存在误解——StringBuilder 本身不支持、也不需要嵌套。所谓“多层嵌套”，通常是开发者误以为要层层包装（比如 new StringBuilder().append(new StringBuilder()...)），或在循环中反复创建新实例并试图“套用”，结果造成大量未及时丢弃的 StringBuilder 实例，其底层 char 数组持续占堆，GC 无法回收，最终引发内存压力甚至 OOM。
明确 StringBuilder 没有嵌套结构
StringBuilder 是一个可变容器，内部持有一个 char[]（或 byte[]，JDK9+），所有 append、insert、delete 操作都在这个数组上原地修改或扩容。它不封装其他 StringBuilder，也不构成层级关系。所谓“嵌套写法”，例如：
-
sb.append(new StringBuilder().append("a").append("b"))→ 这里只是把 inner StringBuilder 的 toString() 结果（即 String）传给了外层 append，inner 实例用完即弃，但若频繁新建，就白白消耗对象创建和 GC 成本 -
for (...) { sb = new StringBuilder().append(...); }→ 每次都丢弃旧 sb、新建一个，旧实例连同其大数组一起滞留堆中
真正阻碍 char 数组回收的关键原因
底层 char 数组能否被回收，取决于 StringBuilder 实例本身是否还被强引用。常见卡点如下：
- 在方法内创建 StringBuilder，却作为返回值长期持有（如放进静态 Map 或缓存池），而没清空内容或重置容量
- 复用 StringBuilder 时只调用
setLength(0)，但未重置内部数组容量；即使内容清空，大数组仍保留，后续 append 若未超限，就不会扩容，但内存也没释放 - 将 StringBuilder 作为字段保存在长生命周期对象中（如 Servlet 实例、Spring Bean），且未做线程隔离或复用管理，导致实例堆积
正确复用与及时释放的实操建议
目标是让 StringBuilder 实例可控、轻量、可回收：
- 单线程场景：在作用域起点创建一次，用完立即 setLength(0)，而不是新建；若需跨方法复用，确保调用方负责清空，避免残留数据干扰
- 避免“new 了不用”：不要为了链式调用临时 new 一个 StringBuilder 又不保留引用，尤其在日志、拼接中间字符串等短生命周期场景中
- 大容量场景下主动 trim：如果确定后续不会再用到当前容量，可调用
sb.setLength(0); sb.trimToSize();，强制缩小内部数组（注意 trimToSize 是 JDK15+ 才有的方法；老版本可用new StringBuilder(sb.length()).append(sb)替代，但仅在必要时用） - 高并发批量拼接：不共享同一个 StringBuilder 实例；优先用 ThreadLocal<StringBuilder> 管理每个线程专属实例，初始化时预设合理容量，避免线程间竞争和误复用
替代思路：绕过内存累积的拼接模式
当拼接总量远超单机内存承受能力（比如拼千万行日志），与其死磕 StringBuilder 容量，不如换范式：
- 流式写出：逐条生成字符串，直接 write 到 FileWriter / ByteArrayOutputStream / HttpServletResponse.getOutputStream()，不累积中间 String 或 StringBuilder
- 分批聚合：将大数据切分为 1w 行/批，每批用独立 StringBuilder 拼好后转为 String 写出，该批 StringBuilder 随即脱离作用域，数组可被快速回收
- 用 CharSequence 或 Supplier 延迟计算：如 SLF4J 占位符日志，参数不拼接、不转 String，直到真正需要输出时才执行，从根本上规避无意义的数组分配
