聊一聊ThreadLocal内存泄漏的问题

article/2025/8/19 11:02:21

回答任何一个问题的时候应该要遵循：明确题意-->深入浅出-->举例说明-->总结，这四个步骤很重要，可以让你沉着冷静，思路清晰，避免尴尬。

01 — 明确题意

明确题意的意思就是先明确一下面试官的题目，能避免自己理解有误而跑题，可以这样说：ThreadLocal内存泄漏的原因主要是因为ThreadLocal中包含了ThreadLocalMap，然而ThreadLocalMap的对象是在Thread中的，如果Thread没有结束，则ThreadLocalMap一直不会释放，假如ThreadLocalMap中设置了很多值，而且没有手动设置remove()，则可能会造成内存泄露。网上有些网友的答案是因为ThreadLocal作为一个弱引用的key然后造成每次GC的时候会回收掉ThreadLocal，导致无法访问value，然后造成了内存泄漏，这是完全错误的，其实和弱引用没有关系。

02 — 深入浅出

先思考一下，如果每次GC都把ThreadLocal给回收掉，那么业务代码在运行的时候出现GC，ThreadLocal被回收之后，业务代码就会获取不到值，这样就会出现问题。弱引用的定义确实是在GC的时候就会被回收掉，如果ThreadLocal又被其它强引用指向了，则它是不会被回收的，想想我们在使用ThreadLocal的时候，我们是怎么定义并使用他的呢？

可以看到threadLocal可以定义为一个全局的静态变量或者是一个局部变量，threadLocal是强引用，不管怎么样它都不会被回收掉，只是又将它的引用又给到了ThreadLocalMap中的Entry.key中，虽然这个key是弱引用，但是ThreadLocal对象是不会被回收的。

如果一个线程Thread结束了，那么Thread里面的threadLocals将会被回收掉，也就是ThreadLocalMap数据结构会被回收掉，也就不会出现内存泄漏的问题。那出现内存泄露的情况是什么呢？

当Thread一直没有结束时，Thread中的threadLocals就不会被回收，threadLocals里面存储的Entry如果不手动删除的话，就会一直存在这个threadLocals里面，所以就会出现内存泄漏的问题，通常在线程池的情况下，一个Thread会使用很长时间，如果在使用的过程中，一直向里面设置Entry，也就是key = ThreadLocal 和 value=业务对象，如果一个线程的任务执行完毕之后，没有手动设置remove()方法释放掉这个Entry的话，那么Thread的threadLocals中的Entry将会一直膨胀，一直停留在Thread中的threadLocals中，造成内存泄漏，所以一定要手动设置remove()。

那这会延伸出来另外一个问题，为什么使用弱引用？

弱引用的作用就是当出现GC的时候会回收这些弱引用的对象，如果有些业务不是定义的全局的静态变量而是局部的变量，例如：通过ThreadLocal保存一些在整个线程中全局都可以使用的变量，减少方法与方法调用的参数传递。此时当一个任务执行完成之后，可以将ThreadLocal设置成为null，局部变量的强引用就会失效，存在Map中的Entry的key只有弱引用，如果不进行清理的话，则会出现内存泄漏的问题，此时出现GC的时候就会回收掉ThreadLocal对象，也就是说ThreadLocal是尽量的去避免内存泄漏的问题。但是解决不了根本的问题，所以需要开发人员手动去调用remove()方法才能够彻底解决内存泄漏的问题。

03 — 举例说明

找到了一个开源项目ruoyi框架的源码，可以看到ThreadLocal是一个全局的静态变量，不同的线程不会影响彼此，ThreadLocal永远不会被回收掉，在线程池的情况下，当我们操作完之后，需要手动调用remove()方法，上图也提供了clearDataSourceType()方法用来清除任务执行完之后的Entry对象。