ThreadLocal是什么？有哪些用途？你了解多少？

今天药忘吃喽~ 2022-09-03 13:20 274阅读 0赞

**点击关注公众号，利用****碎片时间学习****![180c5e39029ed38404f91241c3c63d01.png][]**

本次给大家介绍重要的工具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来给开发者分配任务。

下面再举个栗子，进一步说明他们之间的关系：

![3395350eefa689237ee4b0a9343d6c8a.png][]

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

![78c1ddad4f4bde8b2a4a1625b865635e.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管理类：

![2f2a44647e64d24274bf974ef885b26a.png][]

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

![75e39df6668df3f5cbcab80e874dd039.png][]

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

![041c4f8b03f5a381e0184064b04b13d9.png][]

不出意外我们的结果为：

![fd06c97a7bb0aebac4fd037c6f10d85a.png][]

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

## 3.ThreadLocal原理 ##

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

![77a83afa97be0617165de823e3f338b6.png][]

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

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

![1a5b8766798d2e40f76f96e474746437.png][]

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

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

我们以get方法为例:

![d489b0f9cb547dc4d620ecab435d1534.png][]

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

![120d50b8a2c5d2bb26aee5ff091cc9f9.png][] ![6883fbe92071f1bca9152e184c3fc695.png][]

set的过程也类似：

![3359a9dbd83851476c69f4769229b568.png][]

注意：ThreadLocal中可以直接t.threadLocals是因为Thread与ThreadLocal在同一个包下，同样Thread可以直接访问`ThreadLocal.ThreadLocalMap threadLocals = null;`来进行声明属性。另外，欢迎关注公众号Java笔记虾，后台回复“后端面试”，送你一份面试题宝典！

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

我经常在网上看到骇人听闻的标题，ThreadLocal导致内存泄漏，这通常让一些刚开始对ThreadLocal理解不透彻的开发者，不敢贸然使用。越不用，越陌生。这样就让我们错失了更好的实现方案，所以敢于引入新技术，敢于踩坑，才能不断进步。

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

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

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

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

![e7f05f74235123dc1030218dfdbfc06a.png][]

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

![bf95a3da0730ee327772ad83769266c3.png][]

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

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

![e3e2dbeb3898b2e975c71d5048ac41fd.png][]

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

![f43b69d2cf0a8261acde092361e43247.png][]

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

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

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

![9aaeb6c13e1bad1fc750be43ae31681f.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[可视化分析工具][Link 2]，来查看对内存，分析对象实例的存活状态：

![146093e6719b87472e484d6ebfb5e091.png][] ![6e326b02a3986ddc1ba5bc84a536f1bd.png][]

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

![4af4f4fa0e17cd64a4bd4adeb07a70eb.png][]

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

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

![0407e44d16f19bf7945fdfa46b036cd6.png][] ![2c05f226360019e9ab4052ead1760bee.png][]

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

文中源码：

> https://github.com/z-one/basictest/tree/master/src/main/java/com/spring/test/threadlocal

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

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

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

**①ThreadLocal申明为private static final。**

*  Private与final 尽可能不让他人修改变更引用，
 *  Static 表示为类属性，只有在程序结束才会被回收。

**②ThreadLocal使用后务必调用remove方法。**

*  最简单有效的方法是使用后将其移除。

以上。

*（感谢阅读，希望对你所有帮助)*

*来源：blog.csdn.net/zzg1229059735/article/details/82715741*

推荐好文

[强大，10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程！][10k_ SpringBoot]

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

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

[180c5e39029ed38404f91241c3c63d01.png]: /images/20220829/b7102a3895db465dbf17c12c6fb0060a.png
[3395350eefa689237ee4b0a9343d6c8a.png]: /images/20220829/36b6cc8786034fbda2b070720576cc4e.png
[78c1ddad4f4bde8b2a4a1625b865635e.png]: /images/20220829/987d48e1f12845ee8b9e6ed596b0b9b8.png
[2f2a44647e64d24274bf974ef885b26a.png]: /images/20220829/4668210574fd494e9efa3197761ca14c.png
[75e39df6668df3f5cbcab80e874dd039.png]: /images/20220829/d8e02c82d387406396ed430201c28e26.png
[041c4f8b03f5a381e0184064b04b13d9.png]: /images/20220829/abe817717ccd4a4cbf3a9314d5990767.png
[fd06c97a7bb0aebac4fd037c6f10d85a.png]: /images/20220829/846e34b03d76451b95c55e936a01579a.png
[77a83afa97be0617165de823e3f338b6.png]: /images/20220829/d5051fe1b5224f59b00d1b0687ee5d30.png
[1a5b8766798d2e40f76f96e474746437.png]: /images/20220829/a7772d6cd7e64d74a05ca9b2b2795fee.png
[d489b0f9cb547dc4d620ecab435d1534.png]: /images/20220829/5c7d4af792ad4da0be50aebc243c54e2.png
[120d50b8a2c5d2bb26aee5ff091cc9f9.png]: https://img-blog.csdnimg.cn/img_convert/120d50b8a2c5d2bb26aee5ff091cc9f9.png
[6883fbe92071f1bca9152e184c3fc695.png]: /images/20220829/43dcf64adebe4c8cba5c51ec5946842b.png
[3359a9dbd83851476c69f4769229b568.png]: /images/20220829/3b7097511eb84cd9a71563faf2f06263.png
[e7f05f74235123dc1030218dfdbfc06a.png]: /images/20220829/f552b6b1c50442469a3f7a004d3a1a4b.png
[bf95a3da0730ee327772ad83769266c3.png]: /images/20220829/9751f4c1c2e94509b768f916d19a22af.png
[e3e2dbeb3898b2e975c71d5048ac41fd.png]: /images/20220829/e3a0efab758e429a85c771685c6ef281.png
[f43b69d2cf0a8261acde092361e43247.png]: /images/20220829/6ab1fe28ec5c4981bfdfd420a76af40f.png
[9aaeb6c13e1bad1fc750be43ae31681f.png]: /images/20220829/19272f4009f24def959f1f361aa3f13a.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc7a75adcb0dfcbb7a4f411f2be6dfab73be1cfe81a6b05d07b44b5a19fb6b9ade2346bcb5f7&idx=1&mid=2247489539&scene=21&sn=fdd594895f0b3b3a37c06c7c9dc9560b#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc79bfa0cb0e36b6afda69d4fff84be8d4f70383c75a8bc4e8146d132d9fc652b57c95ae626d&idx=2&mid=2247504398&scene=21&sn=6e1923c4b02438228a590e7ca1a32f85#wechat_redirect
[146093e6719b87472e484d6ebfb5e091.png]: https://img-blog.csdnimg.cn/img_convert/146093e6719b87472e484d6ebfb5e091.png
[6e326b02a3986ddc1ba5bc84a536f1bd.png]: /images/20220829/6e00159a4bba49fba6b5715944669ed0.png
[4af4f4fa0e17cd64a4bd4adeb07a70eb.png]: /images/20220829/cc20c5acf3b04bd6bd4faf72efa1f7a2.png
[0407e44d16f19bf7945fdfa46b036cd6.png]: https://img-blog.csdnimg.cn/img_convert/0407e44d16f19bf7945fdfa46b036cd6.png
[2c05f226360019e9ab4052ead1760bee.png]: /images/20220829/3d92ee0d1c6e4bb78b67695d57f94999.png
[10k_ SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ%3D%3D&chksm=ebd5c411dca24d07446a4f22772cd12d2cc1143b62eb922a14500ae981cd57fb850ef74ca257&idx=2&mid=2247498557&scene=21&sn=84902d7030e174e152615d8fae3755cc#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
[0c28afc967f40ea81c02ebfe5903bd46.png]: /images/20220829/aae216ed8dc84adabb33fe845aa7e7f5.png