stringbuffer无需手动释放资源，其内存由jvm自动管理；但长期持有大容量实例会造成堆内存浪费，可通过trimtosize()收缩内部数组，或改用性能更优的stringbuilder。
StringBuffer 本身不持有需要显式释放的外部资源（如文件句柄、网络连接或 native 内存），所以不需要像流或数据库连接那样调用 close() 或 dispose()。它的内存由 JVM 自动管理，对象不再被引用时会随垃圾回收自动清理。
理解 StringBuffer 的内存行为
StringBuffer 底层使用 char 数组存储内容，数组容量可能大于实际字符长度（即存在“冗余容量”）。虽然它不会导致内存泄漏，但长期持有大容量 StringBuffer 实例，且后续只读不扩容，会造成堆内存浪费。
- 扩容机制：当 append 等操作超出当前容量时，StringBuffer 会创建更大的新数组，复制旧内容，原数组等待 GC
- 初始容量默认为 16；可通过构造函数指定，避免频繁扩容
- capacity() 返回当前内部数组长度，length() 返回实际字符数
主动收缩内部数组（必要时）
如果 StringBuffer 经历过大量追加后又大幅删减（例如 clear() 或 delete(0, length())），其内部数组仍保持较大容量。此时可调用 trimToSize() 让数组大小收缩到当前字符长度：
StringBuffer sb = new StringBuffer(1024);
sb.append("some long text...");
sb.setLength(0); // 清空内容，但 capacity 仍是 1024
sb.trimToSize(); // 此时 capacity ≈ length() ≈ 0，数组被缩小
注意：trimToSize() 是唯一能主动减少 StringBuffer 内部数组占用的方法，但它不释放对象本身——对象生命周期仍由引用决定。
避免长期持有无用实例
真正影响资源释放的是对象引用，而非 StringBuffer 特性：
- 局部变量无需手动置 null —— 方法结束，引用自然消失
- 若 StringBuffer 是类成员变量，且所属对象长期存活，而该 StringBuffer 不再使用，应设为 null（尤其在缓存、静态字段或监听器中）
- 在循环中反复新建 StringBuffer 比复用更安全，避免意外状态残留和容量膨胀
替代建议：优先考虑 StringBuilder
除非需要多线程安全，否则推荐用 StringBuilder：
- 功能几乎完全一致
- 无同步开销，性能更好
- 同样无需手动释放资源，同样支持 trimToSize()
- 语义更清晰：表明该字符串构建场景是单线程的
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
