stringbuffer 不会直接导致 oom，但频繁扩容会引发大量数组拷贝、加速堆内存消耗并加重 gc 压力，最终可能触发 java.lang.outofmemoryerror: java heap space；真正安全的方式是预设合理初始容量以避免扩容。
StringBuffer 本身不会直接导致内存溢出（OOM），但频繁扩容可能引发大量临时数组拷贝、堆内存快速消耗，尤其在高并发或大数据量拼接场景下，间接加剧 GC 压力，最终诱发 java.lang.OutOfMemoryError: Java heap space。真正“安全扩容”的核心不是让扩容变安全，而是**尽量避免扩容发生**。
扩容触发条件必须清楚
扩容不是看“已经用了多少”，而是看“马上要放多少”是否超出当前底层数组容量：
-
判断公式：当前字符数（
count） + 待追加字符串长度 > 底层数组长度（value.length） - 例如：
new StringBuffer(16)，调用append("0123456789abcdef012345")（22 字符）→ 0 + 22 > 16 → 立即扩容 - 再如：已存 15 个字符（
count == 15），再append("ab")→ 15 + 2 = 17 > 16 → 同样触发
扩容过程本身就有开销
每次扩容都是一次完整内存重分配，包含三步不可省略的操作：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 分配一块新 char[]（JDK9+ 可能是 byte[]），大小按规则计算
- 调用
Arrays.copyOf(value, newCapacity)逐字拷贝全部已有内容 - 将内部
value引用指向新数组，旧数组等待 GC
这意味着：拼接 200 字符若从默认 16 开始，大概率经历 4 次扩容（16→34→70→142→200），每次都要复制前序所有字符——CPU 和内存双浪费。
最有效的方法：预设合理初始容量
不靠扩容“兜底”，而是在构造时就给足空间。关键不是精确，而是让最终 length() 落在 capacity() 的 80%~90% 区间：
-
静态模板拼接（如日志格式）：模板字面长度 + 各变量最大可能长度 + 10~20 字符余量
例："uid={}&order={}&ts={}"（19 字） + uid≤32 + order≤64 + ts≤13 → 总计约 130，可设new StringBuffer(144)或向上取整到 128/192 -
循环内拼接多行数据（如 CSV）：单行平均长度 × 行数 × 1.2，或直接按上限预估
例：每行约 80 字符 × 100 行 = 8000，加 10% 余量 → 设new StringBuffer(8800)；也可取 2 的幂如 8192 或 16384 -
完全未知但有硬上限：按上限值设置，比如最多拼 5000 字符，就直接
new StringBuffer(5000)
还要避开几个典型陷阱
即使设了容量，错误用法仍会让优化失效：
- 不要在构造后调用
ensureCapacity()补救——它仍是扩容操作，已发生的拷贝无法撤销 - 避免把 StringBuffer 声明为
static或长期持有的成员变量，否则底层数组会持续膨胀且无法释放 - 循环中复用必须在循环外创建，而不是每轮
new StringBuffer()——否则每次都是新实例，默认 16 容量，白费预估 - 别盲目设极大值（如 10MB），实际只拼几百字符，既浪费堆内存，又拖慢 GC
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
