ThreadLocal内存泄漏及弱引用的理解

最新推荐文章于 2025-06-15 21:10:05 发布

原创最新推荐文章于 2025-06-15 21:10:05 发布 · 1.9k 阅读

4 ·

CC 4.0 BY-SA版权

java 专栏收录该内容

8 篇文章

订阅专栏

本文解析了ThreadLocal中内存泄漏的原因，探讨了Entry的key为何采用弱引用及其与内存泄漏的关系，并提供了预防内存泄漏的方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1.什么是内存泄漏？Entry的key弱引用与泄漏关系

在TreadLocal中内存泄漏是指TreadLocalMap中的Entry中的key为null，而value不为null。因为key为null导致value一直访问不到，而根据可达性分析，始终有threadRef->currentThread->threadLocalMap->entry->valueRef->valueMemory,导致在垃圾回收的时候进行可达性分析的时候,value可达从而不会被回收掉，但是该value永远不能被访问到，这样就存在了内存泄漏。

因为Entry的key是弱引用，所以在gc的时候key会被回收，而value是强引用，导致value不会被回收。

如果不使用弱引用也会可能会发生内存泄漏，只要在业务代码里，将ThreadLocal的引用置为null，也会导致Entry中value访问不到,但又因为可达，所以gc时候不会被回收，相当于这部分内存资源被浪费了

2.为什么Entry的key使用弱引用

假设threadLocal使用的是强引用，在业务代码中执行threadLocal Instance=null操作，以清理掉threadLocal实例的目的，但是因为threadLocalMap的Entry强引用threadLocal，因此在gc的时候进行可达性分析，threadLocal依然可达，对threadLocal并不会进行垃圾回收，这样就无法真正达到业务逻辑的目的，出现逻辑错误。

假设Entry弱引用threadLocal，尽管会出现内存泄漏的问题，但是在threadLocal的生命周期里（set,getEntry,remove）里，都会针对key为null的脏entry进行处理。

3.预防内存泄漏

ThreadLocal源码中其实已经对内存泄漏问题做了很多优化，在set，get，remove方法中都会对key为null的但是value不为null的Entry进行value置null操作，使得value的引用为null，可达性失败，在gc是可以回收value的内存。

在日常使用中，最后用完TreadLocal后，记得remove，为什么呢？

因为如果不remove，当一次gc执行，这个value就会造成内存泄漏直到当前线程结束（线程结束，ThreaLocalMap会被置为null，而ThreaLocalMap中的Entry自己也就不可达，会被回收，一切都被回收）

线程结束时会执行Thread.exit方法

private void exit() {
    if (group != null) {
        group.threadTerminated(this);
        group = null;
    }
    /* Aggressively null out all reference fields: see bug 4006245 */
    target = null;
    /* Speed the release of some of these resources */
    threadLocals = null;
    inheritableThreadLocals = null;
    inheritedAccessControlContext = null;
    blocker = null;
    uncaughtExceptionHandler = null;
}

具体可以参考https://www.jianshu.com/p/dde92ec37bd1 写得非常仔细非常好