ThreadLocal巨坑！内存泄露只是小儿科

本文将会详细总结 ThreadLocal 容易用错的三个坑：

• 内存泄露

• 线程池中线程上下文丢失

• 并行流中线程上下文丢失

内存泄露

由于 ThreadLocal 的 key 是弱引用，因此如果使用后不调用 remove 清理的话会导致对应的 value 内存泄露。

@Test
public void testThreadLocalMemoryLeaks() {
    ThreadLocal<List<Integer>> localCache = new ThreadLocal<>();
   List<Integer> cacheInstance = new ArrayList<>(10000);
    localCache.set(cacheInstance);
    localCache = new ThreadLocal<>();
}

当 localCache 的值被重置之后 cacheInstance 被 ThreadLocalMap 中的 value 引用，无法被 GC，但是其 key 对 ThreadLocal 实例的引用是一个弱引用。

本来 ThreadLocal 的实例被 localCache 和 ThreadLocalMap 的 key 同时引用，但是当 localCache 的引用被重置之后，则 ThreadLocal 的实例只有 ThreadLocalMap 的 key 这样一个弱引用了，此时这个实例在 GC 的时候能够被清理。

其实看过 ThreadLocal 源码的同学会知道，ThreadLocal 本身对于 key 为 null 的 Entity 有自清理的过程，但是这个过程是依赖于后续对 ThreadLocal 的继续使用。

假如上面的这段代码是处于一个秒杀场景下，会有一个瞬间的流量峰值，这个流量峰值也会将集群的内存打到高位（或者运气不好的话直接将集群内存打满导致故障）。

后面由于峰值流量已过，对 ThreadLocal 的调用也下降，会使得 ThreadLocal 的自清理能力下降，造成内存泄露。

ThreadLocal 的自清理是锦上添花，千万不要指望他雪中送碳。

相比于 ThreadLocal 中存储的 value 对象泄露，ThreadLocal 用在 web 容器中时更需要