ThreadLocal
先上几个常见面试题
- ThreadLocal中ThreadLocalMap的数据结构和关系?
- ThreadLocal的key是弱引用,这是为什么?
- ThreadLocal内存泄漏问题你知道吗?
- ThreadLocal中最后为什么要加remove方法?
- ……
什么是ThreadLocal
ThreadLocal提供线程局部变量。这些变量与正常的变量不同,因为每一个线程在访问ThreadLocal实例的时候(通过其geti或set方法)都有自己的、独立初始化的变量副本。ThreadLocal实例通常是类中的私有静态字段,使用它的目的是希望将状态(例如,用户ID或事务ID)与线程关联起来。
ThreadLocal能干嘛
实现每一个线程都有自己专属的本地变量副本(自己用自己的变量不麻烦别人,不和其他人共享,人人有份,人各一份),主要解决了让每个线程绑定自己的值,通过使用get)和l.set()方法,获取默认值或将其值更改为当前线程所存的副本的值从而避免了线程安全问题,比如我们之前讲解的8锁案例,资源类是使用同一部手机,多个线程抢夺同一部手机使用,假如人手一份是不是天下太平??
阿里巴巴开发手册中定义:必须回收自定义的ThreadLocal变量,尤其在线程池场景下,线程经常会被反复利用,如果不清理自定义的ThreadLocal变量,可能会影响后续业务逻辑和造成内存泄漏等问题。尽量在代理中使用try-finally块进行回收

1 | |
输出:
1 | |
Thread、ThreadLocal、ThreadLocalMap关系

打开Thread类,我们可以看到
1 | |
说明Thread包含ThreadLocal,ThreadLocal又包含静态内部类ThreadLocalMap


ThreadLocalMap的entry继承了弱引用,这点后面会涉及到
ThreadLocalMap实际上就是一个以threadLocal实例为key,任意对象为value的Entry对象,当我们为threadLocal变量赋值,实际上就是以当前threadLocal实例为key,值为value的Entry往这个ThreadLocalMap中存放
生动形象描述


JVM内部维护了一个线程版的Map
ThreadLocal内存泄漏
什么是内存泄漏?
不再会被使用的对象或者变量占用的内存不能被回收,就是内存泄漏

java技术允许使用finalize()方法在垃圾收集器将对象从内存清除出去之前做必要的清理善后工作

ThreadLocalMap从字面上就可以看出这是一个保存ThreadLocal对象的map(以ThreadLocal为key),不过是经过了两层包装的ThreadLocalMap对象:
- 第一层包装是使用了WeakReference<ThreadLocal<?>>将ThreadLocal对象变成一个弱引用的对象
- 第二层包装是定义了一个专门的类Entry来扩展WeakReference<ThreadLocal<?>>
回顾Java中的引用类型
强引用
当内存不足,JVM开始垃圾回收,对于强引用的对象,就算是出现了OOM也不会对该对象进行回收,死都不收。
强引用是我们最常见的普通对象引用,只要还有强引用指向一个对象,就能表明对象还“活着”,垃圾收集器不会碰这种对象。在Java 中最常见的就是强引用,把一个对象赋给一个引用变量,这个引用变量就是一个强引用。当一个对象被强引用变量引用时,它处于可达状态,它是不可能被垃圾回收机制回收的,即使该对象以后永远都不会被用到,JVM也不会回收。因此强引用是造成Java内存泄漏的主要原因之一。
对于一个普通的对象,如果没有其他的引用关系,只要超过了引用的作用域或者显式地将相应(强)引用赋值为 null一般认为就是可以被垃圾收集的了(当然具体回收时机还是要看垃圾收集策略)。
1 | |
输出:
1 | |
软引用
软引用是一种相对强引用弱化了一些的引用,需要用java.lang.ref.SoftReference类来实现,可以让对象豁免一些垃圾收集。
对于只有软引用的对象来说:
- 当系统内存充足时,它不会被回收
- 当系统内存不充足时,它会被回收
软引用通常在对内存敏感的程序中,比如高速缓存就有用到软引用,内存够用的时候就保留,不够用就回收
1 | |
输出:
1 | |
弱引用
弱引用需要用java.lang.ref.WeakReference类来实现,它比软引用的生存期更短,对于只有弱引用的对象来说,只要垃圾回收机制一运行,不管JVM的内存空间是否足够,都会回收该对象占用的内存
1 | |
适用场景:
假如有一个应用需要读取大量的本地图片:
- 如果每次读取图片都从硬盘读取则会严重影响性能
- 如果一次性全部加载到内存中有可能造成内存溢出
此时使用软引用可以解决这个问题
设计思路是:用一个HashMap来保存图片的路径和相应图片对象关联的软引用之间的映射关联关系,在内存不足时,JVM会自动回收这些缓存图片对象所占用的空间,从而有效避免了OOM的问题。
1 | |
虚引用
虚引用需要java.lang.ref.PhantomReference类来实现,顾名思义,就是形同虚设,与其他几种引用都不同,虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用,那么它就和没有任何引用一样,在任何时候都可能被垃圾回收器回收,它不能单独使用也不能通过它访问对象,虚引用必须和引用队列(ReferenceQueue)联合使用。
虚引用的主要作用是跟踪对象被垃圾回收的状态。仅仅是提供了一种确保对象被finalize以后,做某些事情的通知机制。PhantomReference的get方法总是返回null,因此无法访问对应的引用对象。
换句话说,设置虚引用关联对象的唯一目的,就是在这个对象被收集器回收的时候收到一个系统通知或者后续添加进一步的处理,用来实现比finalize机制更灵活的回收操作
总结

关系

ThreadLocal是一个壳子,真正的存储结构是ThreadLocal里有ThreadLocalMap这么个内部类,每个Thread对象维护着一个ThreadLoclMap的引用, ThreadLocalMap是ThreadLocal的内部类,用Entry来进行存储。
- 调用ThreadLocal的set()方法时,实际上就是往ThreadLocalMap设置值,key是ThreadLocal对象,值Value是传递进来的对象
- 调用ThreadLocal的get()方法时,实际上就是往ThreadLocalMap获取值,key是ThreadLocal对象
ThreadLocal本身并不存储值(ThreadLocal是一个壳子),它只是自己作为一个key来让线程从ThreadLocalMap获取value。正因为这个原理,所以ThreadLocal能够实现“数据隔离”,获取当前线程的局部变量值,不受其他线程影响~
ThreadLocal的key是弱引用,这是为什么?

line1新建了一个ThreadLocal对象,t1是强引用指向这个对象;
line2调用set()方法后新建了一个entry,通过源码可知Entry对象里的Key是弱引用指向这个对象

为什么源代码用弱引用?
当function01方法执行完毕后,栈帧销毁强引用t1也就没有了。但此时线程的TreadLocalMap里某个entry的key的引用还指向这个对象
- 若这个key引用是强引用,就会导致key指向的ThreadLocal对象及V指向的对象不能被gc回收,造成内存泄漏
- 若这个key引用是弱引用就大概率会减少内存泄漏的问题(还有一个key为null的雷,后面说)。使用弱引用就可以使ThreadLocal对象在方法执行完毕后顺利被回收且entry的key引用指向null
当ThreadLocal被回收之后,TreadLocalMap的entry是一个key为null的K-V键值对,那么我们无法清除V,而且线程池的线程是复用的,所以V值越积越多会导致内存泄漏
所以弱引用不能100%保证内存不泄露,我们要在不适用某个ThreadLocal对象后,手动用remove()方法删除它
并且,通过分析set、get、remove方法看出,在threadlocal的生命周期里,针对threadlocal存在的内部泄漏滴滴问题,都会通过expungeStaleEntry、cleanSomeSlots、replaceStaleEntry这三个方法清理掉key为null的脏entry
remove:寻找脏Entry,即key=null的Entry,然后进行删除
ThreadLocal最佳实践
- ThreadLocal.withInitial(()->初始化值)记得初始化避免空指针异常
- 建议把Threadlocal修饰为static
- 强制:记得用完手动remove