前言
内存泄漏问题，我发现网上很多描述是ThreadLocals的Entry的key为弱引用，在gc时，threadLocal对象被回收，造成key为null，value无法清除的问题，从而导致内存泄漏。我先说明观点，这次现象是存在的，但是在业务代码里是不可能出现的。
内存泄漏
前置条件
首先，在定义内存泄漏之前，我们应该统一一下写法。
我觉得我们首先思考ThreadLocal是用来干嘛的，保存各线程的成员变量，可以是用户信息，可以是数据库或者缓存查出来的信息等等。。
ThreadLocal解决的问题是定义一个全局的统一变量，线程在各个栈帧里都可以拿到这个对象里的值，避免你在各个方法里重复的传递参数。
我大概率会这么用：
public class ThreadLocalUtil {
/**
* 用户id
*/
private static ThreadLocal<Integer> userIdLocal = new ThreadLocal<>();
/**
* 用户名称, 实际开发中肯定不会这么浪费资源。仅做demo用。
*/
private static ThreadLocal<String> userNameLocal = new ThreadLocal<>();
}
定义一个工具类，把ThreadLocal定义为static，这样我就可以在所有类的所有方法中去拿到线程set进去的值、而不需要进行参数传递。
内存分布
假设我们有一个web程序，线程池里有三个线程，每个线程在方法的入口都会被拦截器拦住，解析cookie或者token，然后把userid和username放到ThreadLocal里，那么内存里大概是这个样子的。
看不清的可以点开下面这个链接：threadlocal
虚线的是弱引用，实线的是强引用。
我们可以注意到，threadlocal对象始终有强引用，无论是类的静态的成员变量，或者虚拟机栈引用的对象，都是可以作为gc root的，那么我们创建的两个threadlocal对象始终都无法被gc回收。这也就解释了
为什么我说threadLocalMap的entry的key不可能为null。
内存泄漏场景（不使用remove）
第一点
如果线程没有被回收（可能是被线程池管理，或者短时间内创建了大量的线程），那么每个线程对象内，都维护了一个threadLocalMap, 假设我们在项目里定义了50个threadlocal，有50个线程，每个线程内都维护了50个threadlocal的key-value缓存，那么极限情况下，就有2500个key-value缓存同时存在。如果value比较大，是有可能把内存撑爆的。
第二点
假设这2500个key-value缓存没有把内存撑爆，那么始终会占据一部分不小的内存，假设是30%，如果其他业务代码，需要用到大量的内存操作，比如80%，那么同样也会oom，这次oom，其他业务代码负主要责任，但是这2500个key-value缓存，同样也是造成oom的凶手，因为没有这些缓存，是不会发生oom的。所以不remove掉这些键值对，会增大oom的风险。
第三点
什么时候key是null？当这个threadlocal没有被虚拟机栈引用，没有被类静态成员变量引用，那么threadlocal是会在下一次gc的时候被回收的，这个时候key为null。写法就是在方法内new一个threadlocal，我认为这种写法本身就失去了用threadlocal的目的，我是想不到这样的写法在什么场景下适用，如果有，也请评论区留言，我修正文章观点。
总结
- threadlocal用完一定要手动remove。
- threadlocal用的好，对代码整洁度和层次设计都是很有帮助的，小伙伴们快在自己的业务代码中用起来吧。
- 水平有限，文章中有错误的地方，也请不吝指正，共同进步。
