threadlocal变量不会因虚拟机栈销毁而清除，其值存于线程的threadlocalmap中；线程复用时未调用remove()会导致value强引用泄漏，须在finally中显式清理，推荐static final声明并配合ttl解决跨线程传递问题。
ThreadLocal变量本身不会因“虚拟机栈销毁”而自动清除——这是常见误解。虚拟机栈（Java方法调用的局部变量、操作数栈等）与ThreadLocal的生命周期完全无关。ThreadLocal的数据实际存储在每个线程对象持有的ThreadLocalMap中，该Map是线程级别的堆内存结构，只要线程还活着，Map就一直存在，栈帧结束对其毫无影响。
真正的问题在于线程复用场景下未清理value
多数泄漏发生在使用线程池（如Tomcat工作线程、自定义ExecutorService）时：任务执行完，局部变量随栈帧自然消失，但ThreadLocal.set()写入的value仍留在线程的ThreadLocalMap里。由于Entry的key是弱引用（指向ThreadLocal实例），而value是强引用，一旦ThreadLocal实例被回收（比如static引用被置为null），key变成null，value却无法被GC——它仍被ThreadLocalMap.Entry强持有，且线程长期存活，导致value对象持续驻留堆中。
- 典型泄漏链：线程池线程 → ThreadLocalMap → Entry(key=null, value=大对象) → 大对象无法回收
- 不是“栈销毁没清”，而是“线程不终止，Map不清，value卡死”
必须在业务逻辑末尾显式调用remove()
remove()是唯一能主动断开value强引用的操作。务必在try-finally或统一出口处执行，确保异常也不遗漏：
- Web过滤器/拦截器中：doFilter()结束后立即clear()
- Spring AOP环绕通知：在proceed()后、返回前调用remove()
- 线程池提交Runnable/Callable：包裹逻辑，finally块内remove()
静态声明+及时清理是最稳妥组合
将ThreadLocal声明为private static final，既避免ThreadLocal实例本身被过早回收（防止key=null提前出现），又便于全局统一管理。但注意：static只是让ThreadLocal对象长存，不等于value自动安全——仍需每次使用后remove()。
- 错误写法：
threadLocal.set(new byte[1024*1024]); // 不remove，百万请求后OOM - 正确写法：
try { threadLocal.set(...); } finally { threadLocal.remove(); }
借助TransmittableThreadLocal规避父子线程传递风险
若需在线程池中传递上下文（如日志traceId），原生ThreadLocal无法跨线程继承，强行set会导致子线程残留。此时应改用阿里开源的TransmittableThreadLocal（TTL），它会在submit/run时自动copy并自动清理，从机制上降低误用风险。
