高性能场景下复用 stringbuilder 的核心是避免反复创建、控制内存分配、防止扩容开销并明确线程安全边界；关键在于复用位置、清空方式（setlength(0)）和容量预估，推荐 threadlocal 管理每线程实例，禁用 static 共享与 stringbuffer 混用。
在高性能场景下复用 StringBuilder 的核心是：避免反复创建新实例、控制内存分配节奏、防止扩容开销，并确保线程安全边界清晰。关键不在“能不能复用”，而在于“在哪复用、怎么清空、容量怎么设”。
单次任务中复用一个实例，用 setLength(0) 重置
同一逻辑流程（如一次 HTTP 响应组装、一条 SQL 构建、一个 JSON 片段生成）内，所有拼接步骤共用同一个 StringBuilder 实例。每次开始新拼接前调用 setLength(0)，它比 delete(0, length()) 更快——不检查索引、不移动字符，只重置长度计数器。
- 初始化时预估总长，例如拼接 200 个平均 50 字符的字段，加 199 个逗号，预估 ≈ 200×50 + 199 = 10199 → new StringBuilder(10240)
- 不要在循环体里 new StringBuilder()，哪怕只循环几十次，GC 压力也会明显上升
- 链式调用保持紧凑：sb.append(name).append(',').append(age).append(',').append(city)
高频循环场景下用 ThreadLocal 管理实例
当方法被频繁调用（如日志格式化、模板渲染），且每次调用都需要独立拼接，可借助 ThreadLocal 每线程持有一个预分配容量的 StringBuilder，既免锁又控内存。
- 定义：private static final ThreadLocal
TL_SB = ThreadLocal.withInitial(() -> new StringBuilder(512)) - 使用：StringBuilder sb = TL_SB.get(); sb.setLength(0); sb.append(...)
- 无需手动 remove，线程结束时由 JVM 自动清理；若线程长期存活（如线程池），建议在 finally 块中 TL_SB.remove()
小心 null 和 toString() 的陷阱
append(null) 在 JDK 8+ 会直接抛 NullPointerException；而 append(obj) 对 null 会写入字符串 "null"，这常导致脏数据。toString() 一旦调用就固化内容并复制数组，后续再 append 就浪费了前面那一次复制。
- 对可能为 null 的字段，统一用 Objects.toString(field, "") 或三元判断：field == null ? "" : field.toString()
- 所有 append 操作完成后再调用 toString()，不要中间穿插
- 若需判断拼接结果长度或首字符，用 sb.length() 或 sb.charAt(0)，别提前转 String
别和 StringBuffer 混用，也别跨线程共享
StringBuffer 是 synchronized 的，但高并发下锁竞争严重，吞吐反而下降。除非明确需要跨线程拼接（极少见），否则不要把它当“更安全的 StringBuilder”来用。
- 多线程各自用自己的 StringBuilder，或通过 ThreadLocal 分配
- 绝对不要把 StringBuilder 设为 static 或注入到单例里供多请求共用
- 如果必须合并多个线程的结果，用无锁方式收集（如 ConcurrentLinkedQueue
），最后由单线程用 StringBuilder 拼接
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
