高并发下应复用StringBuilder而非频繁创建，推荐ThreadLocal缓存并预设容量，用setLength(0)清空；避免toString后继续append；复杂场景可用对象池；日志优先用SLF4J占位符。
在高并发场景下（如日志拼接、动态报文生成），频繁创建和丢弃 String 或短生命周期的 StringBuilder 实例，会显著增加 GC 压力，引发内存抖动。关键不是“用不用 StringBuilder”，而是**如何复用它、控制其生命周期，并规避线程安全陷阱**。
用 ThreadLocal 缓存 StringBuilder 实例
每个线程独占一个可复用的 StringBuilder，避免频繁 new，也无需加锁：
private static final ThreadLocal<StringBuilder> STRING_BUILDER_TL = ThreadLocal.withInitial(() -> new StringBuilder(1024)); // 预分配合理初始容量
// 使用示例
public String buildLog(String userId, String action, long costMs) {
StringBuilder sb = STRING_BUILDER_TL.get();
sb.setLength(0); // 清空内容，比 new 更轻量
sb.append('[').append(System.currentTimeMillis()).append("] ")
.append("user=").append(userId)
.append(", action=").append(action)
.append(", cost=").append(costMs).append("ms");
return sb.toString();
}
注意：setLength(0) 是核心——它只重置字符长度，不触发数组扩容或重建，比 new StringBuilder() 或 sb.delete(0, sb.length()) 更高效；预设初始容量（如 1024）可大幅减少扩容次数。
避免隐式 toString() 后继续追加
调用 toString() 后，StringBuilder 内部 char 数组仍被持有，若后续又调用 append()，会因内容已“脱离”而无法复用（尤其在 ThreadLocal 场景中易被误认为安全）：
立即学习“Java免费学习笔记（深入）”；
- ❌ 错误写法：获取字符串后还往同一个实例追加
- ✅ 正确做法：每次逻辑单元内完成全部拼接，再
toString()；或明确 reset（setLength(0)）后再复用
报文生成场景：结合对象池（如 Apache Commons Pool）
当报文结构复杂、字段多、且对延迟敏感时，ThreadLocal 可能导致内存占用偏高（如线程数多、每个 StringBuilder 预分配大）。此时可用轻量对象池管理：
- 定义池工厂，创建带初始容量的
StringBuilder - 使用前
borrow()，用完立即returnObject(sb) - 池配置 maxIdle=20、minIdle=5、softMinEvictableIdleTimeMillis=60000，平衡复用率与内存驻留
比 ThreadLocal 更可控，适合生命周期跨多个方法、或需统一回收策略的场景。
日志框架中慎用 StringBuilder 拼接（推荐参数化）
SLF4J / Log4j2 等现代日志框架本身支持占位符（如 log.info("user {} action {}", userId, action)），底层已做懒拼接（仅当开启 DEBUG 日志时才真正执行 StringBuilder 操作）。直接手拼反而绕过优化，还可能引入线程安全问题。除非有特殊格式要求（如二进制报文转 hex），否则优先走框架原生 API。
