ThreadLocal内存泄漏主因是线程复用时未调用remove()，导致value强引用滞留；须在finally或afterExecute中显式清理，并配合static final声明与TTL跨线程传递方案。
因为长周期运行的线程（如定时调度线程、监听线程、netty eventloop 线程等）生命周期远超普通方法调用，其栈帧长期驻留，若在其中声明并持续持有大体积局部变量（如大数组、大 map、未释放的 bytebuffer、缓存的全量数据列表），这些对象会因强引用关系无法被 gc 回收，最终随线程存活而不断累积，挤占堆内存空间。
为什么局部变量会“不释放”？
局部变量本身作用域结束即不可达，但以下情况会让它实际“挂住”大量内存：
- 变量指向的对象被其他长生命周期对象间接引用（例如：往静态缓存里 put 了该局部 Map 的引用）
- 使用了 Lambda 或匿名内部类捕获该变量，且该函数式对象被注册为监听器或回调，未注销
- 局部 ByteBuffer 是 DirectBuffer，分配在堆外，但对应的 Cleaner 和堆内引用未及时触发清理
- 局部 List 被 add 进 ThreadLocal 的 value 中，而 ThreadLocal 没有 remove()，导致该 List 随线程一直存在
典型高危场景
这些写法看似“只是局部变量”，实则埋下 OOM 隐患：
- 在 @Scheduled 方法中一次性查出百万条 DB 记录并存入局部 ArrayList，再逐条处理——即使方法结束，若该 List 被误传给异步任务或缓存，就逃逸了
- Netty ChannelHandler 中，在 channelActive() 里 new 一个 10MB 的 byte[10_000_000] 并赋值给局部变量，又没及时 clear 或 recycle
- 自定义线程池中，Worker 线程 run() 方法内反复构造大对象并仅靠局部变量持有，但任务队列堆积 + 线程复用，使旧对象引用链迟迟不中断
怎么避免？关键三招
不是禁用局部变量，而是控制它的“体积”和“生命周期边界”：
- 分批处理 + 即时丢弃：大数据集用流式迭代（JDBC Stream / Spring Data Chunking），处理完一批立刻置 null 或用 try-with-resources 自动关闭
- 规避大对象逃逸：检查是否无意将局部集合、缓冲区、Builder 实例传递给了静态容器、监听器、ThreadLocal 或异步回调
- 强制资源归还：对 DirectByteBuffer、MappedByteBuffer、PooledByteBuf 等，必须显式调用 buffer.release() 或 buffer.clear()；ThreadLocal 使用后务必 tl.remove()
