Java ThreadLocal 与 OOM
ThreadLocal 实例通常都是 static 类型,用于关联线程和线程上下文。
ThreadLocal 提供线程内的局部变量,不同的线程之间不会相互干扰,这种变量在线程的生命周期内起作用,减少同一个线程内多个函数或组件之间一些公共变量传递的复杂度。
总结:
- 线程并发: 在多线程并发的场景下
- 传递数据: 我们可以通过ThreadLocal在同一线程,不同组件中传递公共变量
- 线程隔离: 每个线程的变量都是独立的,不会互相影响
一、ThreadLocal 的内部结构
JDK 早期 ThreadLocal 设计:
- 每个 ThreadLocal 都创建一个 Map
- 线程作为 Map 的 key,要存储的局部变量作为 Map 的 value
这样就能达到各个线程的局部变量隔离的效果。
在 JDK8 中 ThreadLocal 的设计:
- 每个 Thread 线程内部都有一个 Map (ThreadLocalMap)
- Map 里面存储 ThreadLocal 对象(key)和线程的变量副本(value)
- Thread 内部的 Map 是由 ThreadLocal 维护的,由 ThreadLocal 负责向 map 获取和设置线程的变量值。
对于不同的线程,每次获取副本值时,别的线程并不能获取到当前线程的副本值,形成了副本的隔离,互不干扰。
这样设计的好处有如下两个优势:
- 每个 Map 存储的 Entry 数量会变少。因为之前的存储数量由 Thread 的数量决定,现在是由 ThreadLocal 的数量决定。在实际运用当中,往往 ThreadLocal 的数量要少于 Thread 的数量。
- 当 Thread 销毁之后,对应的 ThreadLocalMap 也会随之销毁,减少内存的使用。
二、OOM
public class ThreadLocal<T> { static class ThreadLocalMap { private Entry[] table; static class Entry extends WeakReference<ThreadLocal<?>> { // 弱引用
Java 中的引用有 4 种类型: 强、软、弱、虚。当前这个问题主要涉及到强引用和弱引用:
- 强引用(StrongReference):最常见的普通对象引用,只要还有强引用指向对象,就表明对象还“活着”,垃圾回收器就不会回收这种对象。
- 弱引用(WeakReference):垃圾回收器一旦发现了只有弱引用的对象,不管当前内存是否充足,都会回收。
如果 key 使用强引用
- 假设在业务代码中使用完 ThreadLocal ,ThreadLocal Ref 被回收了。
- 但是因为 ThreadLocalMap 的 Entry 强引用了 ThreadLocal,造成 ThreadLocal 无法被回收。
- 在没有手动删除这个 Entry 以及 CurrentThread 依然运行的前提下,始终有强引用链 threadRef -> currentThread -> threadLocalMap -> entry,Entry 就不会被回收(Entry 中包括了 ThreadLocal 实例和 value),导致 Entry 内存泄漏。
也就是说,ThreadLocalMap 中的 key 使用了强引用,是无法完全避免内存泄漏的。
如果 key 使用弱引用
- 同样假设在业务代码中使用完 ThreadLocal,ThreadLocal Ref 被回收了。
- 由于 ThreadLocalMap 只持有 ThreadLocal 的弱引用,没有任何强引用指向 ThreadLocal 实例,所以 ThreadLocal 就可以顺利被 gc 回收,此时 Entry 中的 key=null。
- 但是在没有手动删除这个 Entry 以及 CurrentThread 依然运行的前提下,也存在有强引用链 threadRef -> currentThread -> threadLocalMap -> entry -> value,value 不会被回收,而这块 value 永远不会被访问到了,导致 value 内存泄漏。
也就是说,ThreadLocalMap 中的 key 使用了弱引用,也有可能内存泄漏。
出现内存泄漏的真实原因
比较以上两种情况,可以发现内存泄漏的发生跟 ThreadLocalMap 中的 key 是否使用弱引用是没有关系的。在以上两种内存泄漏的情况中,都有两个前提:
- 没有手动删除这个 Entry
- CurrentThread 依然运行
第一点,只要在使用完 ThreadLocal,调用其 remove 方法删除对应的 Entry,就能避免内存泄漏。
第二点,由于 ThreadLocalMap 是 Thread 的一个属性,被当前线程所引用,所以它的生命周期跟 Thread 一样长。那么在使用完 ThreadLocal 之后,如果当前 Thread 也随之执行结束,ThreadLocalMap 自然也会被 gc 回收,从根源上避免了内存泄漏。
综上,ThreadLocal 内存泄漏的根源是:由于 ThreadLocalMap 的生命周期跟 Thread 一样长,如果没有手动删除对应 key 就会导致内存泄漏。
为什么使用弱引用
无论 ThreadLocalMap 中的 key 使用哪种类型引用都无法完全避免内存泄漏,跟使用弱引用没有关系。
要避免内存泄漏有两种方式:
- 使用完 ThreadLocal,调用其 remove 方法删除对应的 Entry
- 使用完 ThreadLocal,当前 Thread 也随之运行结束
相对第一种方式,第二种方式显然更不好控制,特别是使用线程池的时候,线程结束是不会销毁的。
也就是说,只要记得在使用完 ThreadLocal 及时的调用 remove,无论 key 是强引用还是弱引用都不会有问题。那么为什么 key 要用弱引用呢?
事实上,在 ThreadLocalMap 中的 set/getEntry 方法中,会对 key 为 null(也即是 ThreadLocal 为 null)进行判断,如果为 null 的话,会把 value 也设置为 null 的。
这就意味着使用完 ThreadLocal,CurrentThread 依然运行的前提下,就算忘记调用 remove 方法,弱引用比强引用可以多一层保障:弱引用的 ThreadLocal 会被回收,对应的 value 在下一次 ThreadLocalMap 调用 set、get、remove 中的任一方法的时候会被清除,从而避免内存泄漏。
Hash 冲突
解决办法和 HashMap 不一样,ThreadLocalMap 使用的是线性探测法(开放定址法),HashMap 使用的是拉链法(链地址法)。
该方法一次探测下一个地址,直到有空的地址后插入,若整个空间都找不到空余的地址,则产生溢出。
举个例子:假设当前 table 长度为 16,也就是说如果计算出来 key 的 hash 值为 14,如果 table[14] 上已经有值,并且其 key 与当前 key 不一致,那么就发生了 hash 冲突,这个时候将 14 加 1 得到 15,取 table[15] 进行判断,这个时候如果还是冲突会回到 0,取 table[0],以此类推,直到可以插入。可以把 Entry[] table 看成一个环形数组。
https://www.bilibili.com/video/BV1N741127FH