ThreadLocal的问题有哪些

这篇文章主要介绍“ThreadLocal的问题有哪些”，在日常操作中，相信很多人在ThreadLocal的问题有哪些问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”ThreadLocal的问题有哪些”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

1. 问

连环四问：

• ThreadLocal的原理?

• 内存泄漏的原因?

• InheritableThreadLocal用过吗?

• Netty的FastThreadLocal是什么?

2. 分析

ThreadLocal作为实现“线程封闭”的最主要的编程手段，经常被使用。比如，比如，传统的SimpleDateFormat，不是线程安全的。如果你声明成全局变量，在并发环境下就会产生时间错乱。一种好的解决方式，就是使用ThreadLocal。

ThreadLocal使用非常广泛。比如，Spring的事务管理，就是通过它实现的。但它的弱点也是有的，不能透传(不能被子线程获取)，所以催生了InheritableThreadLocal，甚至更高级的封装库。

3. 答

3.1 ThreadLocal的原理?

看过源码就不难回答。如下图(这张图最易懂)，ThreadLocal的get和remove方法，只不过是一个使用的快捷方式。它的真正数据，是存在于线程中的一个叫做ThreadLocalMap的结构里。

一个ThreadLocal的值，会根据线程的不同，分散在N个线程中。所以获取ThreadLocal的Value，有两个步骤。

• 第一步，根据线程获取Map

• 第二部，根据自身从Map中获取值，所以它的this就是Map的Key

这没什么原理。这就是一个为了照顾编码习惯的数据结构。

3.2 内存泄漏的原因?

严格来说，ThreadLocal没有内存泄漏问题。有的话，那就是你忘记执行remove方法。这是不正确使用引起的。

这和其他一些内存泄漏的问题是一致的，比如：

• 流没有关闭

• 连接没有断开

• 滥用static map

为什么会有泄漏问题?

如果你不调用remove方法的话，ThreadLocal所对应的值，就会存在，一直到当前线程的销毁。

众所周知，线程的生命周期都比较长，加上现在普遍使用的线程池，会让线程的生命更加长。不remove，当然不会释放。这和Key，到底是不是弱引用，关系不大。

那这种情况，属不属于泄漏问题，是一个咬字眼的问题。面试的过程是探讨，并不一定要标准的答案。

比起内存泄漏问题，线程池所引起的数据错乱问题，更加应该引起关心。因为放在ThreadLocal的数据，肯定不会很大，泄漏顶多占用一点内存而已;而数据错乱，可是会引起业务Bug的。

3.3 InheritableThreadLocal用过吗?

InheritableThreadLocal在父子线程传递值的时候用到过，解决了threadlocal不能在父子线程间传值的问题。

这个在本质上，还是通过Thread来实现的。通过两个Map来进行属性拷贝。

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

不要高兴太早，对于使用线程池的情况，由于会缓存线程，线程是缓存起来反复使用的。这时父子线程关系的上下文传递，已经没有意义。

附加问：你如何解决的?

阿里这里有个库，https://github.com/alibaba/transmittable-thread-local  专门解决变量跨线程共享。如果你面的阿里，不妨顺便舔一把。

3.4 Netty的FastThreadLocal是什么

既然Java中有了ThreadLocal类了，为什么Netty还自己创建了一个叫做FastThreadLocal的结构?

我们首先来看一下ThreadLocal的实现。

Thread类中，有一个成员变量threadLocals，存放了与本线程相关的所有自定义信息。对这个变量的定义在Thread类，而操作却在ThreadLocal类中。

问题就出在ThreadLocalMap类上，它虽然叫Map，但却没有实现Map的接口。如图，ThreadLocalMap在rehash的时候，并没有采用类似HashMap的数组+链表+红黑树的做法，它只使用了一个数组，使用开放寻址(遇到冲突，依次查找，直到空闲位置)的方法，这种方式是非常低效的。

由于Netty对ThreadLocal的使用非常频繁，Netty对它进行了专项的优化。它之所以快，是因为在底层数据结构上做了文章，使用常量下标对元素进行定位，而不是使用JDK默认的探测性算法。

底层的InternalThreadLocalMap对cacheline也做了相应的优化。

到此，关于“ThreadLocal的问题有哪些”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！