ThreadLocal 内存泄漏问题

ThreadLocal 用于存储线程本地的变量，如果创建了一个 ThtreadLocal 变量，在多线程访问这个变量的时候，每个线程都会在自己线程的本地内存中创建一份变量的副本，从而起到线程隔离的作用。

Thread、ThreadLocal、ThreadLocalMap 之间的关系：

每一个Thread对象均含有一个ThreadLocalMap类型的成员变量threadLocals，它存储本线程所有的ThreadLocal对象及其对应的值.

ThreadLocalMap由一个个的Entry<key,value>对象构成，Entry继承自weakReference<ThreadLocal<?>>，一个Entry由ThreadLocal对象和Object构成。

Entry 的 key 是ThreadLocal对象，并且是一个弱引用。当指向key的强引用消失后，该key就会被垃圾收集器回收。
Entry 的 value 是对应的变量值，Object 对象。

当执行set方法时，ThreadLocal首先会获取当前线程 Thread 对象，然后获取当前线程的ThreadLocalMap对象，再以当前ThreadLocal对象为key，获取对应的 value。

由于每一条线程均含有各自私有的 ThreadLocalMap 对象，这些容器相互独立互不影响，因此不会存在线程安全性问题，从而也就无需使用同步机制来保证多条线程访问容器的互斥性。

ThreadLocal 使用场景：

1、在进行对象跨层传递的时候，使用ThreadLocal可以避免多次传送，打破层次间的约束。

即如果一个User对象需要从Controller层传到Service层再传到Dao层，那么把User放在ThreadLocal中，每次使用ThreadLocal来进行获取即可

2、线程间数据隔离

3、进行事务操作，用于存储线程事务信息

4、数据库连接，Session会话管理

ThreadLocal 的内存泄漏问题：

这里假设将 ThreadLocal 定义为方法中的局部变量，那么当线程进入该方法的时候，就会将 ThreadLocal 的引用给加载到线程的栈 Stack 中。

如上图所示，在线程栈 Stack 中，有两个变量，ThreadLocalRef 和 CurrentThreadRef，分别指向了声明的局部变量 ThreadLocal ，以及当前执行的线程。

而 ThreadLocalMap 中的 key 是弱引用，当线程执行完该方法之后，Stack 线程栈中的 ThreadLocalRef 变量就会被弹出栈，因此 ThreadLocal 变量的强引用消失了，那么 ThreadLocal 变量只有 Entry 中的 key 对他引用，并且还是弱引用，因此这个 ThreadLocal 变量会被回收掉，导致 Entry 中的 key 为 null，而 value 还指向了对 Object 的强引用，因此 value 还一直存在。 ThreadLocalMap 变量中，由于 ThreadLocal 被回收了，无法通过 key 去访问到这个 value，导致这个 value 一直无法被回收，ThreadLocalMap 变量的生命周期是和当前线程的生命周期一样长的，只有在当前线程运行结束之后才会清除掉 value，因此会导致这个 value 一直停留在内存中，导致内存泄漏。

当然 JDK 的开发者想到了这个问题，在使用 set get remove 的时候，会对 key 为 null 的 value 进行清理，使得程序的稳定性提升。

当然，我们要保持良好的编程习惯，在线程对于 ThreadLocal 变量使用的代码块中，在代码块的末尾调用 remove 将 value 的空间释放，防止内存泄露。

ThearLocal 内存泄漏的根源是：

由于 ThreadLocalMap 的生命周期跟 Thread 一样长，如果没有手动删除对应 key 就会导致内存泄漏。

ThreadLocal 正确的使用方法：

每次使用完 ThreadLocal 都调用它的 remove() 方法清除数据
将 ThreadLocal 变量定义成 private static final，这样就一直存在 ThreadLocal 的强引用，也能保证任何时候都能通过 ThreadLocal 的弱引用访问到 Entry 的 value 值，进而清除掉。

下面给出 ThreadLocal 的用法：

public class ThreadLocalExample {private static final ThreadLocal<Integer> counter = new ThreadLocal<Integer>() {@Overrideprotected Integer initialValue() {return 0;}};public static void main(String[] args) {Thread t1 = new Thread(() -> {try {int value = counter.get(); // 获取当前线程的副本值counter.set(value + 1); // 修改副本值System.out.println("Thread " + Thread.currentThread().getName() + " value: " + counter.get());} finally {// 手动移除counter.remove(); // 在线程结束时移除变量}});Thread t2 = new Thread(() -> {try {int value = counter.get();counter.set(value + 1);System.out.println("Thread " + Thread.currentThread().getName() + " value: " + counter.get());} finally {// 手动移除counter.remove();}});t1.start();t2.start();}
}

那么 ThreadLocal 为什么要将 key 设计为弱引用呢？

这里还要看一下具体是如何使用 ThreadLocal 了：

如果定义 ThreadLocal 为局部变量，那么这个 ThreadLocal 对象就会放在堆中，如果不手动 remove() 的话，当线程执行完当前方法退出时，这个局部变量对 ThreadLocal 的强引用就消失了，只剩下 Thread.ThreadLocalMap 中的 key 对 ThreadLocal 的弱引用，因此会将 ThreadLocal 给回收掉，而 value 还存在强引用，而我们没有了 TheadLocal 的引用导致访问不到 value，导致 value 无法回收，因此 JDK 设计者在 ThreadLocal 还添加了清除。 ThreadLocalMap 中 key 为 null 的 value，避免内存泄漏，这是在设计时为了避免内存泄漏而采取的措施，而我们使用的时候要保持良好的编程规范，也要手动去 remove，避免内存泄露的发生。
如果定义 ThreadLocal 为 private static final，那么这个 ThreadLocal 就会在常量池中存储，而不是存储在堆中，这时候要考虑的问题是当前线程在使用完 ThreadLocal 之后要主动 remove 避免出现脏数据（而不是内存泄漏问题，因为我们可以随时通过该 ThreadLocal 去访问到 ThreadLocalMap 中的 value 值，并随时进行回收，因此不会存在内存泄漏），因为在多线程的环境中，如果上一个线程使用完 ThreadLocal 之后并没有 remove，下一个线程来使用时可能会拿到上个线程的数据，产生了脏数据。