ThreadLocal能解决StringBuilder线程安全问题，因为它为每个线程提供独立实例，彻底消除共享与竞争；正确写法是static final声明并用withInitial初始化，使用后调用remove防止内存泄漏。
StringBuilder 本身不是线程安全的，多线程直接共享同一个实例并调用 append，会导致内部字符数组越界、内容覆盖或数据丢失。用 ThreadLocal 可以为每个线程单独持有一个 StringBuilder 实例，彻底避免竞争，无需加锁，性能也更好。
为什么 ThreadLocal 能解决这个问题
ThreadLocal 为每个线程提供独立的变量副本。每个线程操作的是自己专属的 StringBuilder，彼此互不干扰。它不是“把 StringBuilder 放进全局变量再加锁”，而是从源头上消除共享——根本就没有共享对象。
正确使用 ThreadLocal 的方式
不要直接 new ThreadLocal<StringBuilder>() 后每次 get() 都 new 一个，那样会频繁创建对象；应配合 initialValue() 或 lambda 初始化，确保线程首次访问时才创建，且只创建一次。
- 推荐写法（Java 8+）：
private static final ThreadLocalbuilderHolder = ThreadLocal.withInitial(StringBuilder::new); - 使用时直接调用：
StringBuilder sb = builderHolder.get();
然后放心sb.append("xxx")，无需同步 - 用完注意清理（尤其在线程池场景）：
builderHolder.remove();
防止内存泄漏（ThreadLocalMap 中的 Entry 是弱引用 key，但 value 若不手动 remove，可能长期滞留）
常见误用和坑
直接在方法里 new ThreadLocal<StringBuilder>() 是错的——每次调用都新建一个 ThreadLocal 实例，起不到复用和隔离效果，还浪费资源。
立即学习“Java免费学习笔记（深入）”；
- ThreadLocal 变量必须是
static final，保证全局唯一，才能让所有线程通过它获取各自的副本 - 在线程池（如 Tomcat、ExecutorService）中，线程会被复用，不 remove 会导致前一次请求残留的数据污染下一次请求
- 如果需要重用 StringBuilder（比如清空后继续用），记得调用
setLength(0)，而不是 new 一个新的 —— 这样更轻量
替代方案对比（为什么选 ThreadLocal 而不是其他）
对比 synchronized 或 StringBuffer：前者加锁影响吞吐，后者虽线程安全但每个方法都同步，有性能开销；而 ThreadLocal 完全无锁，适合高频拼接场景（如日志组装、SQL 拼接、模板渲染）。
- 若只是偶尔拼接、并发不高 → 用 StringBuffer 更简单
- 若需跨方法传递、生命周期明确 → 可考虑局部 new StringBuilder，由调用方管理
- 若高并发 + 多次 append + 需复用 → ThreadLocal 是平衡安全性与性能的优选
