ThreadLocal 防内存泄漏关键在及时 remove()：static final + withInitial() 声明，set/get 必配 try-finally 中 remove()，虚线程优先 ScopedValue，需监控 map size 并用 MAT 排查堆积。
用 ThreadLocal 防止内存泄漏，关键不在“怎么设”，而在“怎么收”——不清理，设得再规范也白搭。尤其在线程池或虚线程场景下，一次漏掉 remove()，就可能积压成千上万个无法回收的对象。
声明要稳：static final + withInitial()
避免每次 new 一个 ThreadLocal 实例，也别让 get() 返回 null 引发 NPE：
- 用
static final修饰，确保 key 是全局唯一的强引用（不是为了共享，而是防止 key 过早被弱引用回收） - 优先用
ThreadLocal.withInitial()设置默认值，而不是裸 new 后靠 if 判空 - 别在方法里 new ThreadLocal —— 每次创建都新增 key，极易触发哈希冲突和 entry 泄漏
使用要准：set/get 后必须配对 remove()
ThreadLocal 的 value 是强引用，而 key 是弱引用。key 可能被 GC 掉，但 value 还卡在 ThreadLocalMap 里，等着拖垮内存：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 所有 set() 和 get() 操作，都要包裹在 try-finally 中，finally 里调用 remove()
- 不要依赖“线程结束自动清”，线程池里的线程永不结束，虚线程虽短命但复用 carrier 线程，map 不会自动清
- 如果封装了工具类（如 UserContext），clear() 方法必须暴露且强制调用，不能只写不调
虚线程要格外小心：优先 ScopedValue，次选主动清理
Project Loom 的 VirtualThread 默认复用平台线程，但每个虚线程仍绑定独立 ThreadLocalMap。问题在于：它执行完就销毁，不会触发 Thread.exit() 的清理逻辑：
立即学习“Java免费学习笔记（深入）”；
- 能用
ScopedValue就不用 ThreadLocal —— 它是 Loom 原生支持的、作用域明确、自动清理的替代方案 - 若必须用 ThreadLocal，务必在虚线程任务末尾显式 remove()，且避免在阻塞点（如 sleep、I/O）后才清理
- 可加监控：定期扫描 ThreadLocalMap 的 size，异常增长即告警（比如 > 100 个未清理 entry）
排查与兜底：别等 OOM 才发现
内存泄漏往往静默发生，等报 OutOfMemoryError 就晚了：
- 用 MAT 或 VisualVM 分析 heap dump，筛选
java.lang.ThreadLocal$ThreadLocalMap$Entry，看 value 是否大量堆积 - 检查 classloader 是否被 hold —— 如果 value 持有 Spring Bean 或 ServletContext，容易导致整个 classloader 泄漏
- 上线前加单元测试：模拟线程池反复执行 + 清理断言，验证 remove() 是否真被执行
