引子：

内存泄漏：是指本应该被GC回收的无用对象没有被回收，导致内存空间的浪费，当内存泄露严重时会导致内存溢出。Java内存泄露的根本原因是：长生命周期的对象持有短生命周期对象的引用，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被GC回收。

内存溢出：就是我们常说的OOM（OutOfMemoryError）异常，简单理解就是内存不够了，通常发生在程序申请的内存超出了JVM中可用内存的大小，就会抛出OOM异常。在JVM内存区域中，除了程序计数器外其他的内存区域都有可能抛出OOM异常。

ThreadLocal很好地解决了线程之间需要数据隔离的问题，同时也引入了另一个问题，在应用程序中通常会使用线程池来管理线程，那么线程的生命周期与应用程序的生命周期基本保持一致，如果线程的数量很多，随着程序的运行，时间的推移，ThreadLocal类型的变量会越来越多，将会占用非常大的内存空间，从而产生内存泄漏，如果这些对象一直不被释放的话，可能会导致内存溢出。

 

大家先看一下内存图：

 

从图中可以看出，ThreadLocal对象存在于堆中，有栈中的强引用指向它，也有ThreadLocalMap中的entry的弱引用键指向他。

“弱引⽤：只要垃圾回收机制⼀运⾏，不管JVM的内存空间是否充⾜，都会回收该对象占⽤的内存。”

而随着程序的运行，栈中ThreadLocal的强引用会消亡，只剩下弱引用连接着ThreadLocal独享，由于ThreadLocalMap.Entity中的key是弱引用，所以堆中的ThreadLocal对象会被回收（只要发生GC，弱引用对象就会被回收），但是ThreadLocalMap⽣命周期和Thread是⼀样的，它这时候如果不被回收，就会出现这种情况：ThreadLocalMap的key没了，value还在，这就会造成了内存泄漏问题（由弱引用引起的内存泄漏）。

而对于线程来说，线程的生命周期与应用程序的生命周期基本保持一致，所以一直会存在：Current Thread Refefence -> Thread -> ThreaLocalMap -> Entry -> value -> Object的强引用，这样value所强引用的Object对象迟迟得不到回收，就会导致内存泄漏。

如何解决弱引用导致的内存泄露问题？

ThreadLocalMap的设计中已经考虑到这种情况，所以ThreadLocal的get()、set()、remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。

一旦将value设置为null之后，就斩断了引用与真实内存之间的强引用，就能够真正的释放空间，防止内存泄漏。

但是这只是一种被动的方式，如果这些方法都没有被调用怎么办？那你就每次使用完ThreadLocal变量之后，执行remove方法。

总结：ThreadLocalMap中的弱引用以及调用ThreadLocal各种方法后的清理只是增加了一层防护手段，还是有可能会导致内存泄露，真正想防止内存泄漏，需要编码的规范，使用完ThreadLocal后，及时调用remove()方法释放内存空间。

 

那为什么还要维持一个弱引用呢？

设置ThreadLocal对象的弱引用，这样做的目的是确保ThreadLocal对象在没有其他强引用时可以被垃圾回收。

key设计成弱引⽤同样是为了防⽌内存泄漏（这是另一个原因引起的内存泄漏）。假如key被设计成强引⽤，如果ThreadLocal Reference被销毁，此时它指向ThreadLoca的强引⽤就没有了，但是此时key还强引⽤指向ThreadLoca，就会导致ThreadLocal不能被回收，这时候就发⽣了内存泄漏的问题。

两个内存泄漏问题是不一样的

• 这里是ThreadLocal变量无法被回收，导致内存泄漏；

• 而弱引用导致的则是Value指向的object无法被回收，导致内存泄漏；

总结

首先，如果让key使用强引用指向ThreadLocal，则ThreadLocal对象无法被回收，导致内存泄漏；为了解决这个问题，让key使用弱引用指向Threadlocal，而这也会导致了Value无法被回收，造成内存泄漏，如何解决呢？我们在使用完ThreadLocal对象后，及时使用remove方法释放内存空间即可。