ThreadLocal 能解决 StringBuilder 线程安全问题，因其为每个线程分配独立实例，避免竞争；需 static final 声明、withInitial 初始化、setLength(0) 复用、remove() 清理以防内存泄漏。
StringBuilder 本身不是线程安全的，多线程共用同一个实例调用 append() 会导致字符数组越界、内容覆盖或数据丢失。ThreadLocal 能解决这个问题，因为它不共享对象——每个线程拿到的是自己专属的 StringBuilder 实例，天然隔离，无需加锁。
为什么 ThreadLocal 能做到线程间互不干扰
ThreadLocal 并不是“给共享对象加锁”，而是为每个线程分配独立副本。线程 A 的 sb.append("A") 和线程 B 的 sb.append("B") 操作的是两个完全不同的对象，内存地址不同、char[] 数组不同、count 计数器也各自独立。从根源上消除了竞争条件。
正确声明和使用方式（Java 8+ 推荐）
必须用 static final 声明 ThreadLocal 变量，确保全局唯一；用 withInitial 延迟初始化，避免每次 get() 都新建对象：
-
推荐写法：
private static final ThreadLocal<StringBuilder> sbHolder = ThreadLocal.withInitial(StringBuilder::new); - 获取实例：
StringBuilder sb = sbHolder.get(); - 放心拼接：
sb.append("hello").append(" ").append("world"); - 用完清空（关键！）：
sb.setLength(0);—— 复用缓冲区，比new更轻量
在线程池中必须调用 remove()
Tomcat、ExecutorService 等场景下线程会被复用。若不清理，前一次请求残留的 StringBuilder 可能被下一次请求直接使用，造成数据污染或内存泄漏：
立即学习“Java免费学习笔记（深入）”；
- 在任务结束时执行：
sbHolder.remove(); - 尤其注意：ThreadLocalMap 的 key 是弱引用，但 value 不手动 remove 会一直持有 StringBuilder 及其内部 char[]，长期累积可能引发 OOM
- 建议封装成工具方法，或配合 try-finally / try-with-resources（需包装）确保执行
别踩这些常见坑
- 在方法内
new ThreadLocal<>()—— 每次调用都新建 ThreadLocal 实例，完全失去复用和隔离意义 - 非 static 声明 ThreadLocal 字段 —— 多个对象实例各自持有一套 ThreadLocal，无法统一管理，还浪费资源
- 拼接后直接返回
sb.toString()却忘了setLength(0)或remove()—— 下次 get() 得到的是带旧内容的 StringBuilder - 误以为 “用了 ThreadLocal 就不用管 StringBuilder 容量” —— 频繁扩容仍影响性能，可预设初始容量如
withInitial(() -> new StringBuilder(1024))
