ThreadLocal 为每个线程提供独立变量副本，非线程安全容器；必须重写 initialValue() 或用 withInitial() 初始化，避免 static 误用和内存泄漏；务必在任务结束前调用 remove() 防止因弱引用 key 导致 value 泄漏。
ThreadLocal 的基本用法和初始化陷阱
ThreadLocal 不是“线程安全的容器”，它本身不解决共享变量竞争，而是让每个线程持有一份独立副本。最常踩的坑是误用 static 修饰但未重写 initialValue()，导致所有线程拿到 null 或默认值。
- 必须重写
initialValue()，或使用new ThreadLocal() {{ ... }}（不推荐双大括号，有内存泄漏风险） - 推荐写法：
private static final ThreadLocal<SimpleDateFormat> DATE_FORMAT = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd")); - 不要在构造时直接 new：错误示例
new ThreadLocal<simpledateformat>(new SimpleDateFormat("..."))</simpledateformat>——ThreadLocal构造函数没有接收参数的重载 - 若用
set(null)，后续get()仍返回上次设置的值，不会触发initialValue()
为什么 remove() 不是可选操作而是必做动作
ThreadLocal 的 key 是弱引用，value 是强引用。如果线程长期运行（如线程池中的 Worker 线程），而没调用 remove()，value 无法被回收，造成内存泄漏 —— 这不是理论风险，是 JDK 源码注释里明确警告的行为。
- 在线程任务结束前，必须显式调用
threadLocal.remove() - 尤其在使用
ExecutorService时，务必在finally块中清理：try { dateFormatter.set(...); // do work } finally { dateFormatter.remove(); // 关键！ } - Spring 的
RequestContextHolder就是基于 ThreadLocal 实现，且内部自动调用了reset()（本质是remove()），这就是为什么它能“安全”用于 Web 场景
ThreadLocalMap 的扩容与哈希冲突处理
ThreadLocal 内部靠 ThreadLocalMap 存储数据，它不是 HashMap，没有红黑树优化，哈希冲突采用线性探测（open addressing），且初始容量固定为 16、负载因子为 2/3。这意味着：一旦 key 数量超过 10 个，就可能触发 resize，而 resize 过程会遍历整个表并 rehash —— 对性能敏感场景需警惕。
- 避免在一个线程里创建大量不同 ThreadLocal 实例（比如按请求参数动态 new ThreadLocal）
- 多个逻辑相关的状态，优先考虑封装进一个对象再塞进单个 ThreadLocal：
private static final ThreadLocal<Context> CONTEXT = ThreadLocal.withInitial(Context::new);
- ThreadLocalMap 的
set()在探测过程中遇到 key == null 的 stale entry 会尝试清理，但这不能替代主动remove()
与 InheritableThreadLocal 的关键区别
普通 ThreadLocal 的值不会传递给子线程；InheritableThreadLocal 会在子线程创建时，把父线程的 value（通过 childValue() 方法）复制一份过去。但注意：这个复制只发生在 new Thread() 时，对线程池无效 —— 因为线程池复用线程，不会触发继承逻辑。
立即学习“Java免费学习笔记（深入）”；
- 若需在线程池中传递上下文（如 traceId），不能只靠
InheritableThreadLocal，得配合ThreadPoolExecutor的beforeExecute()手动传递 -
InheritableThreadLocal的childValue()默认直接返回 parent value，若需深拷贝（如ArrayList），必须重写该方法 - Spring 的
TransmittableThreadLocal（TTL）库就是为解决线程池场景下的继承问题而生，它通过装饰Runnable和Callable实现透传
