ThreadLocal 详解(三)内存泄露原因,以及强弱引用

1、ThreadLocal内存泄漏

在Threadlocal的内部静态类中Entry将Threadlocal作为一个key,值作为value保存,他继承WeakReference,super(k),代表了Threadlocal对象是一个弱引用;

java 复制代码
static class Entry extends WeakReference<ThreadLocal<?>> {
    /** The value associated with this ThreadLocal. */
    Object value;

    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

内存泄漏原因:

  • 没有手动删除这个Entry,调用remove()
  • CurrentThread当前线程仍然在运行

对于第一点:只有使用完Threadlocal,调用其remove()删除对应对的Entry,可以避免内存泄漏;

对于第二点:

  • ThreadlocalMap作为Thread的一个变量,只要Thread运行,那么ThreadlocalMap就不会被清理掉。
  • 通过上面源码可以看出,Threadlocal运行在一个方法中,在虚拟机栈的局部变量表中某个slot上,指向了内存空间中该Threadlocal对象,假设调用了get()方法后,ThreadlocalMap中的一个Entry指向了Threadlocal实例,且是弱引用,该方法执行完成,虚拟机栈释放。此时只有ThreadLocalMap中的一个Entry指向ThreadLocal对象
  • 此时发生GC,根据弱引用的特点,如果一个对象只有弱引用,该对象将被回收,此时ThreadlocalMap中出现一个entry(null,Entry)
  • ThreadLocalMap中就会出现 key 为 null 的 Entry。假如我们不做任何措施的话,value 永远无法被 GC 回收,这个时候就可能会产生内存泄露。

总结:由于ThreadLocalMap 的生命周期跟 Thread 一样长,对于重复利用的线程来说,如果没有手动删除(remove()方法)对应 key 就会导致entry(null,value)的对象越来越多,从而导致内存泄漏.

2、为什么不将key设置为强引用

那么为什么ThreadLocalMap的key要设计成弱引用呢?其实很简单,如果key设计成强引用且没有手动remove(),那么key会和value一样伴随线程的整个生命周期。假设在业务代码中使用完ThreadLcoal,ThreadLocal ref被回收了,但是ThreadLocalMap强引用了Threadlocal(Key就是ThreadLocal),造成了ThreadLocal无法被回收。在没有手动回收Entry以及CurrentThread依然运行的前提下,始终有强引用链 CurrentThread Ref -> CurrentThread -> ThreadLocalMap -> entryEntry就不会被回收( Entry中包括了ThreadLocal实例和value), 导致Entry内存泄漏

结尾:喜欢的朋友点个赞吧!!!

相关推荐
我不想当小卡拉米13 小时前
C++:继承+菱形虚拟继承的一箭双雕
开发语言·jvm·c++
时光呢14 小时前
JAVA常见的 JVM 参数及其典型默认值
java·开发语言·jvm
我命由我1234520 小时前
Spring Boot 自定义日志打印(日志级别、logback-spring.xml 文件、自定义日志打印解读)
java·开发语言·jvm·spring boot·spring·java-ee·logback
xyliiiiiL1 天前
ZGC初步了解
java·jvm·算法
心灵Haven1 天前
JVM介绍
jvm
小样vvv1 天前
【面试篇】JVM
jvm·面试·职场和发展
兢兢业业的小白鼠1 天前
Java高级JVM知识点记录,内存结构,垃圾回收,类文件结构,类加载器
java·开发语言·jvm·tomcat
程序猿chen1 天前
《JVM考古现场(十五):熵火燎原——从量子递归到热寂晶壁的代码涅槃》
java·jvm·git·后端·java-ee·区块链·量子计算
Song2 天前
JVM 学习计划表(2025 版)
jvm·学习
皮卡兔子屋2 天前
java虚拟机---JVM
java·jvm