一、原因
实际上 ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用，弱引用的特点是，如果这个对象只存在弱引用，那么在下一次垃圾回收的时候必然会被清理掉。
所以如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候会被清理掉的，这样一来 ThreadLocalMap中使用这个 ThreadLocal 的 key 也会被清理掉。但是，value 是强引用，不会被清理，这样一来就会出现 key 为 null 的 value。
二、解决方案
ThreadLocalMap实现中已经考虑了这种情况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。如果说会出现内存泄漏，那只有在出现了 key 为 null 的记录后，没有手动调用 remove() 方法，并且之后也不再调用 get()、set()、remove() 方法的情况下。
总结：解决方法：当某个ThreadLocal变量（比如：TL_INT）不再使用时，记得TL_INT.remove()，删除该key。
三、线程池使用
使用了线程池，可以达到“线程复用”的效果。但是归还线程之前记得清除ThreadLocalMap，要不然再取出该线程的时候，ThreadLocal变量还会存在。这就不仅仅是内存泄露的问题了，整个业务逻辑都可能会出错。
总结：所以ThreadLocal最好还是不要和线程池一起使用，就没这么多问题了
附录
- 强引用：普通的引用，强引用指向的对象不会被回收；
- 软引用：仅有软引用指向的对象，只有发生gc且内存不足，才会被回收；
- 弱引用：仅有弱引用指向的对象，只要发生gc就会被回收。
1. ThreadLocal.ThreadLocalMap中提到的弱引用，弱引用究竟会不会被回收？
会被回收，如上图所示。key 已经有null的情况了。第一个Key不为null，原因在第二点。在经历过FULL GC后 所有的key都被回收了。
2. 弱引用什么情况下回收？
弱引用在GC(包括MinitorGC和Full GC)时，被扫描到就会被回收，但是有一个前提，该弱引用在外部没有被引用到（这个时候外部的引用等于强引用）。
换句话说，如果我main方法中持有一个key的引用，哪怕他put进Map后被设置为弱引用的，也不会被回收。
3. JAVA的ThreadLocal和在什么情况下会内存泄露？
答案是不会,原因如下图，在我们调用ThreadLocal.set（）的时候，会做一个将Key== null 的元素清理掉的工作，具体做法是：
第一步：ThreadLocalMap 拿threadLocalHashCode与长度减一相与，求出哈希表的位置的 i 。
第二步：编列Entry，如果找到key相等的，覆盖原值! 或者找到key==null的，将值set进去，并且将遍历时路过的key==null的元素和他的value都置为null,,释放内存。
第三步：最后一个if条件时，做rehash的动作，即:将Entry里的元素重新计算一下Hash值，放到合适的位置去，猜想是为了加快下次访问的速度。
总结：
从这里看出，JAVA的ThreadLocal对Key使用到了弱引用，但是为了保证不再内存泄露，在每次set.get的时候主动对key==null的entry做遍历回收。
虽然不会造成内存泄露，但是因为只有在每次set，get的时候才会对entry做key==null的判断，从而释放内存，所以可能使大对象在内存中存活很长一段时间，从而占用内存。
所以，我们在使用完ThreadLocal里的对象后最好能手动remove一下，或者至少调用下ThreadLocal.set(null)。
值得注意的是ThreadLocal中的key是当前当前ThreadLocal自己，就像上面模拟的外部持有强引用的情况，ThreadLocal.ThreadLocalMap中的key==null情况很少出现，因为，大部分情况ThreadLocal是以单例模式一直存在的。
评论区