@@ -106,53 +106,40 @@ ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
106106
107107### ⭐️ThreadLocal 内存泄露问题是怎么导致的?
108108
109- ` ThreadLocalMap ` 中使用的 key 为 ` ThreadLocal ` 的弱引用,而 value 是强引用 。
109+ ` ThreadLocal ` 内存泄漏的根本原因在于其内部实现机制 。
110110
111- 如果 ThreadLocal 使用不当,就会发生内存泄漏,发生内存泄漏需要满足 2 个条件:
111+ 通过上面的内容我们已经知道:每个线程维护一个名为 ` ThreadLocalMap ` 的 map。 当你使用 ` ThreadLocal ` 存储值时,实际上是将值存储在当前线程的 ` ThreadLocalMap ` 中,其中 ` ThreadLocal ` 实例本身作为 key,而你要存储的值作为 value。
112112
113- - ThreadLocal 被定义为方法的局部变量,从而导致 ThreadLocalMap 中的 key 在 GC 之后变为 null。
114- - 线程持续存活(比如线程处在线程池中),导致线程内部的 ThreadLocalMap 对象一直未被回收。
113+ ` ThreadLocalMap ` 的 ` key ` 和 ` value ` 引用机制:
115114
116- ** 通过案例解释为什么会内存泄漏:**
115+ - ** key 是弱引用** :` ThreadLocalMap ` 中的 key 是 ` ThreadLocal ` 的弱引用 (` WeakReference<ThreadLocal<?>> ` )。 这意味着,如果 ` ThreadLocal ` 实例不再被任何强引用指向,垃圾回收器会在下次 GC 时回收该实例,导致 ` ThreadLocalMap ` 中对应的 key 变为 ` null ` 。
116+ - ** value 是强引用** :` ThreadLocalMap ` 中的 value 是强引用。 即使 key 被回收(变为 ` null ` ),value 仍然存在于 ` ThreadLocalMap ` 中,被强引用,不会被回收。
117117
118- 假设将 ThreadLocal 定义为方法中的 ** 局部变量** ,那么当线程进入该方法的时候,就会将 ThreadLocal 的引用给加载到线程的 ** 栈** 中,假设为 ThreadLocalRef。
119- 120- 如下图所示,在线程栈 Stack 中,有两个变量,ThreadLocalRef 和 CurrentThreadRef,分别指向了声明的局部变量 ThreadLocal ,以及当前执行的线程内部的 ThreadLocalMap 变量。
121- 122- ![ image-20241210225928979] ( https://11laile-note-img.oss-cn-beijing.aliyuncs.com/image-20241210225928979.png )
123- 124- 当线程执行完该方法之后,就会将该方法的局部变量从栈中删除。
125- 126- 因此 Stack 线程栈中的 ThreadLocalRef 变量就会被弹出栈,此时 ThreadLocal 变量的强引用消失了,现在只有 Entry 中的 key 对它进行弱引用。
127- 128- 那么这个 ThreadLocal 变量就会被垃圾回收器给回收掉,导致 Entry 中的 key 为 null,同时 value 指向了对 Object 的强引用。
129- 130- 同时假设当前这个线程一直存活,那么 Thread 内部的 ThreadLocalMap 变量就不会被回收,因此 ThreadLocalMap 内部的 Entry 的 value 指向的 Object 对象一直不会被回收,如下图(对线程的引用不一定在 Stack 栈中,还有可能在方法区,这里画在 Stack 栈中是为了方便理解):
131- 132- ![ ThreadLocal 结构和内存泄漏] ( https://11laile-note-img.oss-cn-beijing.aliyuncs.com/ThreadLocal%20%E7%BB%93%E6%9E%84%E5%92%8C%E5%86%85%E5%AD%98%E6%B3%84%E6%BC%8F.jpg )
118+ ``` java
119+ static class Entry extends WeakReference<ThreadLocal<?> > {
120+ /* * The value associated with this ThreadLocal. */
121+ Object value;
133122
134- ** 因此内存泄漏的发生需要满足 2 个条件:**
123+ Entry (ThreadLocal<?> k , Object v ) {
124+ super (k);
125+ value = v;
126+ }
127+ }
128+ ```
135129
136- 1、 ThreadLocal 定义为方法内的局部变量,当方法执行完毕之后,ThreadLocal 被回收,导致无法通过 ThreadLocal 访问到 ThreadLocalMap 内部的 value 。
130+ 当 ` ThreadLocal ` 实例失去强引用后,其对应的 value 仍然存在于 ` ThreadLocalMap ` 中,因为 ` Entry ` 对象强引用了它。如果线程持续存活(例如线程池中的线程), ` ThreadLocalMap ` 也会一直存在,导致 key 为 ` null ` 的 entry 无法被垃圾回收,机会造成内存泄漏 。
137131
138- 2、Stack 线程栈内部的 CurrentThreadRef 引用指向的线程 ** 一直存活 ** ,导致线程内部的 ThreadLocalMap 也无法被回收,从而导致 Entry 的 value 一直存在指向 Object 的强引用,导致 Object 对象无法回收,出现内存泄漏。
132+ 也就是说,内存泄漏的发生需要同时满足两个条件:
139133
140- JDK 团队也考虑到了这种情况,因此在设计 ThreadLocal 时还添加了清除 ThreadLocalMap 中 key 为 null 的 value 的功能,避免内存泄漏。这是在设计阶段为了避免内存泄漏而采取的措施,而我们使用的时候要保持良好的编程规范,正确定义 ThreadLocal,并且手动 remove,避免内存泄漏的发生。
134+ 1 . ` ThreadLocal ` 实例不再被强引用;
135+ 2 . 线程持续存活,导致 ` ThreadLocalMap ` 长期存在。
141136
142- 结论:如果 ` ThreadLocal ` 被定义为方法的局部变量,并且线程一直存活,就会导致内存泄漏的发生 。
137+ 虽然 ` ThreadLocalMap ` 在 ` get() ` , ` set() ` 和 ` remove() ` 操作时会尝试清理 key 为 null 的 entry,但这种清理机制是被动的,并不完全可靠 。
143138
144139** 如何避免内存泄漏的发生?**
145140
146- 遵循阿里巴巴的开发规范:
147- 148- - 将 ThreadLocal 变量定义成 ` private static final ` ,这样就一直存在 ThreadLocal 的强引用,也能保证任何时候都能通过 ThreadLocal 的访问到 Entry 的 value 值,进而清除掉。
149- - 每次使用完 ThreadLocal 都主动调用它的 remove() 方法清除数据。
150- 151- ** 弱引用介绍:**
152- 153- > 如果一个对象只具有弱引用,那就类似于** 可有可无的生活用品** 。弱引用与软引用的区别在于:只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中,一旦发现了只具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。不过,由于垃圾回收器是一个优先级很低的线程, 因此不一定会很快发现那些只具有弱引用的对象。
154- >
155- > 弱引用可以和一个引用队列(ReferenceQueue)联合使用,如果弱引用所引用的对象被垃圾回收,Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。
141+ 1 . 在使用完 ` ThreadLocal ` 后,务必调用 ` remove() ` 方法。 这是最安全和最推荐的做法。 ` remove() ` 方法会从 ` ThreadLocalMap ` 中显式地移除对应的 entry,彻底解决内存泄漏的风险。 即使将 ` ThreadLocal ` 定义为 ` static final ` ,也强烈建议在每次使用后调用 ` remove() ` 。
142+ 2 . 在线程池等线程复用的场景下,使用 ` try-finally ` 块可以确保即使发生异常,` remove() ` 方法也一定会被执行。
156143
157144## 线程池
158145
0 commit comments