ThreadLocal 通过线程级对象复用规避频繁创建开销，适用于 SimpleDateFormat 等线程不安全但不宜全局共享的对象；需配合 withInitial() 初始化、及时 remove() 防泄漏，并利用 TLAB 与逃逸分析优化性能。
ThreadLocal 本身不直接“应对”对象频繁创建开销，而是通过线程级对象复用来规避它。关键不在于 ThreadLocal 多快，而在于你如何用它避免在高并发场景下反复 new 对象。
用 ThreadLocal 缓存线程私有对象，而非每次新建
典型场景如 SimpleDateFormat、ByteBuffer、JSON 解析器、数据库连接上下文等——它们线程不安全，但又不宜全局共享。不用 ThreadLocal 时，可能每处理一个请求都 new 一次；用了之后，每个线程只初始化一次，后续直接复用：
- 静态 ThreadLocal 实例 +
withInitial()是最简方式：private static final ThreadLocal<simpledateformat> SDF = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));</simpledateformat> - 调用处无需判断或创建，直接
SDF.get().parse(...)，无对象分配压力 - 注意：仅适用于无状态或线程内可变但不跨线程共享的场景
配合 TLAB 和逃逸分析，让 ThreadLocal 初始化更轻量
JVM 的 TLAB（Thread Local Allocation Buffer）天然适配 ThreadLocal 模式：每个线程在自己专属内存块中分配对象，无锁、无同步。当 ThreadLocal 中缓存的对象小且生命周期与线程一致时，JIT 很容易将其判定为“未逃逸”，进而优化掉部分构造开销甚至栈上分配。
- 确保 ThreadLocal 的初始值构造逻辑简单（避免复杂计算或 I/O）
- 避免在
withInitial中引用外部大对象或闭包，否则可能干扰逃逸分析 - 在 Java 24+ 中，ThreadLocalMap 哈希冲突减少，get/set 更快，进一步降低访问成本
必须配套 remove()，否则复用反而引发内存泄漏
高并发常搭配线程池使用，线程长期存活。若只 set 不 remove，ThreadLocalMap 中的 Entry 会持续持有对象引用（key 是弱引用，value 是强引用），导致 value 无法回收——这就是典型的“复用变堆积”。
立即学习“Java免费学习笔记（深入）”；
- 在请求结束、任务完成、Filter/Interceptor 退出等明确生命周期终点调用
threadLocal.remove() - 推荐封装成 try-finally 或使用 try-with-resources（自定义 CloseableThreadLocal）
- 不要依赖线程销毁自动清理——线程池里的线程几乎永不销毁
替代方案对比：比对象池更轻，比静态单例更安全
对比其他缓解频繁创建的手段：
- 对象池（如 Commons Pool）：适合重量级、创建开销极大且需控制总量的对象，但引入借用/归还逻辑和并发竞争，复杂度高
- 静态单例：零分配开销，但必须保证线程安全（加锁或无状态），很多工具类做不到
- ThreadLocal：无竞争、无同步、线程隔离天然安全，初始化开销仅一次/线程，综合性价比最高
