全方位，多角度理解ThreadLocal

骑猪看日落 2022-09-07 09:43 121阅读 0赞

**点击关注公众号，实用技术文章****及时了解**![8b97da5f11f4026d9254974365b2b128.png][]

### *来源：blog.csdn.net/zzg1229059735/* ###

### *article/details/82715741* ###

本次给大家介绍重要的工具ThreadLocal。讲解内容如下，同时介绍什么场景下发生内存泄漏，如何复现内存泄漏，如何正确使用它来避免内存泄漏。

*  ThreadLocal是什么？有哪些用途？
 *  ThreadLocal如何使用
 *  ThreadLocal原理
 *  ThreadLocal使用有哪些坑及注意事项

## 1. ThreadLocal是什么？有哪些用途？ ##

首先介绍Thread类中属性threadLocals:

/* ThreadLocal values pertaining to this thread. This map is maintained * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;

我们发现Thread并没有提供成员变量threadLocals的设置与访问的方法，那么每个线程的实例threadLocals参数我们如何操作呢？这时我们的主角：ThreadLocal就登场了。

**所以有那么一句总结：ThreadLocal是线程Thread中属性threadLocals的管理者。**

也就是说我们对于ThreadLocal的get, set，remove的操作结果都是针对当前线程Thread实例的threadLocals存，取，删除操作。类似于一个开发者的任务，产品经理左右不了，产品经理只能通过技术leader来给开发者分配任务。下面再举个栗子，进一步说明他们之间的关系：

![a1f2c200b8da3937021094759fc202ba.png][]

1.  每个人都一张银行卡
2.  每个人每张卡都有一定的余额。
3.  每个人获取银行卡余额都必须通过该银行的管理系统。
4.  每个人都只能获取自己卡持有的余额信息，他人的不可访问。

![fe9c335d969fbf47be43840feb624a82.png][]

映射到我们要说的ThreadLocal

1.  card类似于Thread
2.  card余额属性，卡号属性等类似于Treadlocal内部属性集合threadLocals
3.  cardManager类似于ThreadLocal管理类

**那ThreadLocal有哪些应用场景呢？**

其实我们无意间已经时时刻刻在使用ThreadLocal提供的便利，如果说多数据源的切换你比较陌生，那么spring提供的声明式事务就再熟悉不过了，我们在研发过程中无时无刻不在使用，而spring声明式事务的重要实现基础就是ThreadLocal，只不过大家没有去深入研究spring声明式事务的实现机制。后面有机会我会给大家介绍spring声明式事务的原理及实现机制。

原来ThreadLocal这么强大，但应用开发者使用较少，同时有些研发人员对于ThreadLocal内存泄漏，等潜在问题，不敢试用，恐怕这是对于ThreadLocal最大的误解，后面我们将会仔细分析，只要按照正确使用方式，就没什么问题。如果ThreadLocal存在问题，岂不是spring声明式事务是我们程序最大的潜在危险吗？

## 2.ThreadLocal如何使用 ##

为了更直观的体会ThreadLocal的使用我们假设如下场景

1.  我们给每个线程生成一个ID。
2.  一旦设置，线程生命周期内不可变化。
3.  容器活动期间不可以生成重复的ID

我们创建一个ThreadLocal管理类：

![b4bf02d29c986664d079aabb122afdd0.png][]

测试程序如下：我们同一个线程不断get，测试id是否变化，同时测试完成后我们就将其释放掉。

![c9058d00c8e03cb6f01404986655ccda.png][]

在主程序中我们开启多个线程测试不通线程之间是否会影响

![ba863131a473b82cf8079be3b731aa3d.png][]

不出意外我们的结果为：

![f31d66d9aa64f93e327ba84a42e203f4.png][]

结果：确实是不同线程间id不同，相同线程id相同。

## 3.ThreadLocal原理 ##

#### ①ThreadLocal类结构及方法解析： ####

![855a05909d5b2e515abda676ce2d126b.png][]

上图可知：ThreadLocal三个方法get, set , remove以及内部类`ThreadLocalMap`

#### ②ThreadLocal及Thread之间的关系： ####

![9e6d6d6c67a88ae088282f699083d8c0.png][]

从这张图我们可以直观的看到Thread中属性threadLocals，作为一个特殊的Map，它的key值就是我们ThreadLocal实例，而value值这是我们设置的值。

#### ③ThreadLocal的操作过程： ####

我们以get方法为例:

![ac93d9b2830d65c4faacadf0e8896b72.png][]

其中getMap(t)返回的就上当前线程的threadlocals，如下图，然后根据当前ThreadLocal实例对象作为key获取ThreadLocalMap中的value，如果首次进来这调用setInitialValue()

![cb60c2a2c0e662ab2fa3ace419df6e01.png][] ![58901ce3c66244f1ddbd3dbb246dbd5e.png][]

set的过程也类似：

![2f32b32475b8e6d51247f93952091b75.png][]

注意：ThreadLocal中可以直接t.threadLocals是因为Thread与ThreadLocal在同一个包下，同样Thread可以直接访问ThreadLocal.ThreadLocalMap threadLocals = null;来进行声明属性。

## 4.ThreadLocal使用有哪些坑及注意事项 ##

我经常在网上看到骇人听闻的标题，ThreadLocal导致内存泄漏，这通常让一些刚开始对ThreadLocal理解不透彻的开发者，不敢贸然使用。越不用，越陌生。这样就让我们错失了更好的实现方案，所以敢于引入新技术，敢于踩坑，才能不断进步。另外，关注Java知音公众号，回复“后端面试”，送你一份面试题宝典！

我们来看下为什么说ThreadLocal会引起内存泄漏，什么场景下会导致内存泄漏？

先回顾下什么叫内存泄漏，对应的什么叫内存溢出

*  ①Memory overflow:内存溢出，没有足够的内存提供申请者使用。
 *  ②Memory leak:内存泄漏，程序申请内存后，无法释放已申请的内存空间，内存泄漏的堆积终将导致内存溢出。

显然是TreadLocal在不规范使用的情况下导致了内存没有释放。

![8a9e652c05bf6a3165dcd499a71b768e.png][]

红框里我们看到了一个特殊的类WeakReference，同样这个类，应用开发者也同样很少使用，这里简单介绍下吧

![3674d237c4f69e8be97d1fb0697504f0.png][]

既然WeakReference在下一次gc即将被回收，那么我们的程序为什么没有出问题呢？

#### ①所以我们测试下弱引用的回收机制： ####

![555d31d6baef8705904bf345be654f75.png][]

这一种存在强引用不会被回收。

![e6d1ab61347bae86b3b83b9b5618e150.png][]

这里没有强引用将会被回收。

上面演示了弱引用的回收情况，下面我们看下ThreadLocal的弱引用回收情况。

#### ②ThreadLocal的弱引用回收情况 ####

![f24a41a730cd23ec55f124ae1a85a8ba.png][]

如上图所示，我们在作为key的ThreadLocal对象没有外部强引用，下一次gc必将产生key值为null的数据，若线程没有及时结束必然出现，一条强引用链`Threadref`–>`Thread`–>`ThreadLocalMap`–>`Entry`，所以这将导致内存泄漏。推荐：[面试题仓库][Link 1]

下面我们模拟复现ThreadLocal导致内存泄漏：

**1.为了效果更佳明显我们将我们的treadlocals的存储值value设置为1万字符串的列表：**

class ThreadLocalMemory {
        // Thread local variable containing each thread's ID
        public ThreadLocal<List<Object>> threadId = new ThreadLocal<List<Object>>() {
            @Override
            protected List<Object> initialValue() {
                List<Object> list = new ArrayList<Object>();
                for (int i = 0; i < 10000; i++) {
                    list.add(String.valueOf(i));
                }
                return list;
            }
        };
        // Returns the current thread's unique ID, assigning it if necessary
        public List<Object> get() {
            return threadId.get();
        }
        // remove currentid
        public void remove() {
            threadId.remove();
        }
    }

测试代码如下：

public static void main(String[] args)
                throws InterruptedException {
    
            //  为了复现key被回收的场景，我们使用临时变量
            ThreadLocalMemory memeory = new ThreadLocalMemory();
    
            // 调用
            incrementSameThreadId(memeory);
    
            System.out.println("GC前：key:" + memeory.threadId);
            System.out.println("GC前：value-size:" + refelectThreadLocals(Thread.currentThread()));
    
            // 设置为null，调用gc并不一定触发垃圾回收，但是可以通过java提供的一些工具进行手工触发gc回收。
            memeory.threadId = null;
            System.gc();
    
            System.out.println("GC后：key:" + memeory.threadId);
            System.out.println("GC后：value-size:" + refelectThreadLocals(Thread.currentThread()));
    
            // 模拟线程一直运行
            while (true) {
            }
        }

此时我们如何知道内存中存在memory leak呢？

我们可以借助jdk提供的一些命令dump当前堆内存，命令如下：

jmap -dump:live,format=b,file=heap.bin <pid>

然后我们借助MAT可视化分析工具，来查看对内存，分析对象实例的存活状态：

![de8b4b5020b4562a7906c7327684c1e2.png][] ![f629056cf92cd14f39cc753bf5012a99.png][]

首先打开我们工具提示我们的内存泄漏分析：

![d47caf2699bc259315a15ddafb2b5006.png][]

这里我们可以确定的是ThreadLocalMap实例的Entry.value是没有被回收的。

最后我们要确定Entry.key是否还在？打开Dominator Tree，搜索我们的ThreadLocalMemory，发现并没有存活的实例。

![d68d22146710e322d31f66e91d14183e.png][] ![736c12ec98761dd406887c3a318e9be3.png][]

以上我们复现了ThreadLocal不正当使用，引起的内存泄漏。demo在这里。

所以我们总结了使用ThreadLocal时会发生内存泄漏的前提条件：

*  ①ThreadLocal引用被设置为null，且后面没有set，get,remove操作。
 *  ②线程一直运行，不停止。（线程池）
 *  ③触发了垃圾回收。（Minor GC或Full GC）

我们看到ThreadLocal出现内存泄漏条件还是很苛刻的，所以我们只要破坏其中一个条件就可以避免内存泄漏，单但为了更好的避免这种情况的发生我们使用ThreadLocal时遵守以下两个小原则:

*  ①ThreadLocal申明为private static final。
 *   *  Private与final 尽可能不让他人修改变更引用，
     *  Static 表示为类属性，只有在程序结束才会被回收。
 *  ②ThreadLocal使用后务必调用remove方法。
 *   *  最简单有效的方法是使用后将其移除。

以上。

推荐好文

[**主流Java进阶技术（学习资料分享）**][Java]

[**分享一套基于SpringBoot和Vue的企业级中后台开源项目，代码很规范！**][SpringBoot_Vue]

[**能挣钱的，开源 SpringBoot 商城系统，功能超全，超漂亮**][SpringBoot]![94bcf54316652d2281f7bfa3b29d4030.png][]

[8b97da5f11f4026d9254974365b2b128.png]: /images/20220829/7d541432ac044ffdaf0ac7e96ee0b485.png
[a1f2c200b8da3937021094759fc202ba.png]: /images/20220829/faf10b6ab48744da8df72afd038b8ea1.png
[fe9c335d969fbf47be43840feb624a82.png]: /images/20220829/59697bc51bba46f0a0b9f541e4fc5f2d.png
[b4bf02d29c986664d079aabb122afdd0.png]: /images/20220829/b631846263cf4154941c89ccb3ddc81e.png
[c9058d00c8e03cb6f01404986655ccda.png]: /images/20220829/dda52dd672bc47808f61171debff144e.png
[ba863131a473b82cf8079be3b731aa3d.png]: /images/20220829/c096688480ea4d379c50e70943d46eae.png
[f31d66d9aa64f93e327ba84a42e203f4.png]: /images/20220829/6673b365ffe344b4b95ea4557e451441.png
[855a05909d5b2e515abda676ce2d126b.png]: /images/20220829/5669f2582c624dbfbb0e67eecc1eeeb6.png
[9e6d6d6c67a88ae088282f699083d8c0.png]: /images/20220829/c39418a10254416ba5b37607f2c35e42.png
[ac93d9b2830d65c4faacadf0e8896b72.png]: /images/20220829/87f6fbbd702444d8954b4b22ff1252a0.png
[cb60c2a2c0e662ab2fa3ace419df6e01.png]: https://img-blog.csdnimg.cn/img_convert/cb60c2a2c0e662ab2fa3ace419df6e01.png
[58901ce3c66244f1ddbd3dbb246dbd5e.png]: /images/20220829/379c0aaac61340638acecd15b4b9cb14.png
[2f32b32475b8e6d51247f93952091b75.png]: /images/20220829/387b2b9fb8c94cf690e590d61a649cf9.png
[8a9e652c05bf6a3165dcd499a71b768e.png]: /images/20220829/23c114d1061b4a6286d9d0bb68bfe555.png
[3674d237c4f69e8be97d1fb0697504f0.png]: /images/20220829/e22566dd75db4d679a17592a7be426a7.png
[555d31d6baef8705904bf345be654f75.png]: /images/20220829/d90a58974c66415682a40bbe56279317.png
[e6d1ab61347bae86b3b83b9b5618e150.png]: /images/20220829/935077c12b714864af49968ea8c43bf2.png
[f24a41a730cd23ec55f124ae1a85a8ba.png]: /images/20220829/3dfaf02dd4a8412db19dae10ff7c9f34.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ%3D%3D&chksm=ebd5ed45dca26453c0cf91265d669711a4e2b4ea52f3ff4a00b063a9de46d69fcc599f151210&idx=1&mid=2247504489&scene=21&sn=afd92248113146b086652ad7f89c7a7c#wechat_redirect
[de8b4b5020b4562a7906c7327684c1e2.png]: https://img-blog.csdnimg.cn/img_convert/de8b4b5020b4562a7906c7327684c1e2.png
[f629056cf92cd14f39cc753bf5012a99.png]: /images/20220829/9d431294451441ffa7855b84461ebe55.png
[d47caf2699bc259315a15ddafb2b5006.png]: /images/20220829/b9be227291134744bdd8cd5d897fa4c7.png
[d68d22146710e322d31f66e91d14183e.png]: https://img-blog.csdnimg.cn/img_convert/d68d22146710e322d31f66e91d14183e.png
[736c12ec98761dd406887c3a318e9be3.png]: /images/20220829/8e1447bd16a249558d7d65038e8bf9ba.png
[Java]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc79b1b2cb0e38a498933a034926df45b51524b044762583488d498ae2112c06cf35d412fb3b&idx=2&mid=2247506972&scene=21&sn=790959d9ee2b74e0d0c8a0a5395bc665#wechat_redirect
[SpringBoot_Vue]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799be6cb0e12f0b58479f8b031bc5ae79efdca1880ff9b19f0a107c3a88c37b9596dc73203&idx=2&mid=2247497288&scene=21&sn=65d7111a19e920df1e9416959594b2f4#wechat_redirect
[SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799a9ccb0e138a64a2671f31b8d4be1b3c061a288f7b0d1d4af02a60c45a72231446b91e00&idx=2&mid=2247497522&scene=21&sn=c5b4e596be4ac7d7f293e7e2f0ea0769#wechat_redirect
[94bcf54316652d2281f7bfa3b29d4030.png]: /images/20220829/9874d556be3a409cb69c236456ea53a2.png