stringbuilder 本身线程不安全，应避免共享实例；推荐方法内局部创建、确需共享时用 stringbuffer、高并发场景用 threadlocal，禁用手动加锁。

StringBuilder 本身不支持多线程安全，不能直接“升级”成线程安全版本，但可以根据具体使用场景选择真正安全且合理的替代方案。关键不是强行给 StringBuilder 加锁，而是选对工具、用对方式。

明确是否真需共享同一个实例

多数并发问题其实源于误将 StringBuilder 当作跨线程共享状态容器。如果每个线程只操作自己的 StringBuilder，就根本不需要线程安全——这是最常见也最高效的模式。

• 方法内局部创建：在 Runnable、Callable 或普通方法中 new StringBuilder()，生命周期限于当前线程，天然安全
• 避免逃逸：不要把局部 StringBuilder 传给其他线程（如 executor.submit(() -> sb.append(...))），否则它就变成了共享对象
• Spring/Servlet 环境下尤其注意：@Async 方法、过滤器、拦截器中的变量可能被不同请求线程复用，局部变量仍安全，成员变量则高危

确需共享时优先用 StringBuffer

当业务逻辑确实要求多个线程往同一个字符串缓冲区追加内容（例如集中日志收集、聚合结果拼接），StringBuffer 是标准库中最直接、最可靠的选择。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 所有 public 修改方法（append、insert、delete 等）都带 synchronized，保证操作原子性
• JVM 锁优化（如锁消除、轻量级锁）已在现代 JDK（Java 21+）中大幅降低开销，实测性能差距比十年前小得多
• 无需额外引入依赖，语义清晰，团队协作成本低

高性能高并发场景考虑 ThreadLocal

若 StringBuffer 的同步开销在压测中仍成为瓶颈（如每秒数万次 append），且你控制着线程生命周期（如自定义线程池），ThreadLocal 是更精细的解法。

• 为每个线程分配独立 StringBuilder 实例，彻底避开竞争
• 典型写法：private static final ThreadLocal TL_SB = ThreadLocal.withInitial(StringBuilder::new);
• 使用后建议 clear() 防止内存泄漏（尤其在线程池场景下）
• 适合长期运行、线程复用频繁的服务端组件

避免“伪安全”的加锁方式

手动用 synchronized 包裹 StringBuilder 操作，看似解决问题，实则隐患更多：

• 容易遗漏：一处没加锁，整个逻辑就失效
• 粒度难控：锁整个对象还是某段代码？锁太粗影响吞吐，太细又漏保护
• 与 StringBuffer 本质相同却更易出错，还失去 API 一致性
• 经理说“加锁太笨重”，正是因为它把简单问题复杂化了

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南