threadlocal内存泄漏,threadlocal会内存泄漏吗

threadlocal内存泄漏,threadlocal会内存泄漏吗详细介绍

本文目录一览： threadlocal会内存泄漏吗

随笔篇-ThreadLocal原理分析笔者经常使用ThreadLocal的场景有：ThreadLocal实现结构以及执行的过程如下图所示。ThreadLocal的几个关键词。
ThreadLocal是线程Thread中属性threadLocals即ThreadLocal.ThreadLocalMap的管理者，ThreadLocal用于给每个线程操作自己线程的本地变量，通过线程私有从而保证线程安全性。
threadlocal使用场景和原理是每个线程需要有自己单独的实例，实例需要在多个方法中共享，但不希望被多线程共享。线程同步正好相反，线程同步机制都是为了解决多线程中相同变量的访问冲突问题。
ThreadLocal本质及脏数据、内存泄漏问题1、但是普通的ThreadLocal在创建新线程后信息会完全丢失，笔者曾经在这里踩到过坑。
2、这就导致，下次如果Dubbo处理响应恰好继续使用到这个线程，该线程就能调用到上次响应中设置在ThreadLocal设置的值。这就引起内存泄露，可能还会导致业务上异常。
3、在这个情况下，存在一个线程访问或者修改另一个线程的数据的可能性。当数据不允许这样共享的时候，我们应该做成线程安全的。
4、)方法，在remove和set方法中都会调用这个方法。ThreadLocal为了避免内存泄露，不仅使用了弱引用维护key，还在每个操作上检查key是否被回收，进而再回收value。
5、因此为了避免value内存泄露，我们需要在ThreadLocal不需要的时候主动remove掉。ThreadLocal通过自身的threadLocalHashCode来碰撞得到自己在ThreadLocalMap的table里的索引i。因此这个threadLocalHashCode就十分重要了。
ThreadLocal的使用方法、作用、使用场景和原理ThreadLocal是线程本地变量的意思，即可以将变量控制在当前线程中，这样就避免了多线程并发的复杂处理，Spring中就有大量使用。
ThreadLocal是线程Thread中属性threadLocals即ThreadLocal.ThreadLocalMap的管理者，ThreadLocal用于给每个线程操作自己线程的本地变量，通过线程私有从而保证线程安全性。
)方法，在remove和set方法中都会调用这个方法。ThreadLocal为了避免内存泄露，不仅使用了弱引用维护key，还在每个操作上检查key是否被回收，进而再回收value。
线程局部变量（ThreadLocal）其实的功用非常简单，就是为每一个使用该变量的线程都提供一个变量值的副本，是每一个线程都可以独立地改变自己的副本，而不会和其它线程的副本冲突。
使他的应用场景相对来说更为特殊一些。在android中Looper、ActivityThread以及AMS中都用到了ThreadLocal。当某些数据是以线程为作用域并且不同线程具有不同的数据副本的时候，就可以考虑采用ThreadLocal。
概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式。比如定义一个static变量，同步访问，而ThreadLocal采用了“以空间换时间”的方式。
ThreadLocal1、该方法返回当前线程在该线程局部变量的初始值，这个方法是一个延迟调用方法，在一个线程第1次调用get()或者set(Object)时才执行，并且仅执行1次。
2、threadlocal是针对per-thread的，不会被其他线程并发访问。
3、ThreadLocal为解决多线程程序的并发问题提供了一种新的思路。使用这个工具类可以很简洁地编写出优美的多线程程序，ThreadLocal并不是一个Thread，而是Thread的局部变量。ThreadLocal是Thread的局部变量。

并发编程-Threadlocal

上一篇 <<< Fork/Join框架 下一篇 >>> Disruptor框架
Threadlocal： 各个线程独有的局部变量，相互之间不受影响。 它主要有四个方法initialValue()、get()、set()和remove(),底层采用了map集合形式进行存放，key为当前线程ID。
不管是用强引用还是弱引用都是会发生内存泄漏的问题。弱引用中不会发生ThreadLocal内存泄漏的问题。 但是最终根本的原因Threadlocal内存泄漏的问题，产生于ThreadLocalMap与我们当前线程的生命周期一样，如果没有手动的删除的情况下，就有可能会发生内存泄漏的问题。
相关文章链接： <<< 多线程基础 <<< 线程安全与解决方案 <<< 锁的深入化 <<< 锁的优化 <<< Java内存模型(JMM) <<< Volatile解决JMM的可见性问题 <<< Volatile的伪共享和重排序 <<< CAS无锁模式及ABA问题 <<< Synchronized锁 <<< Lock锁 <<< AQS同步器 <<< Condition <<< CountDownLatch同步计数器 <<< Semaphore信号量 <<< CyclicBarrier屏障 <<< 线程池 <<< 并发队列 <<< Callable与Future模式 <<< Fork/Join框架 <<< Disruptor框架 <<< 如何优化多线程总结

什么是ThreadLocal？解决了什么问题？

首先加深印象： 1.ThreadLocal解决的是每个线程需要有自己独立的实例，且这个实例的修改不会影响到其他线程。 这个ThreadLocal的用法一般都是创建各自线程自己运行过程中单独创建的对象的，不适合的相同实例共享的。 https://ask.csdn.net/questions/764337 ThreadLocal存入的对象就不该是同一个。这玩意不保证线程安全。 所谓的副本是指，A线程存入的值，对B线程并不感知，B只能拿到自己存的值，并不能拿到A存入的值。 因为一般情况下ThreadLocal 都是定义为static类型的，如果没有ThreadLocal，那么B线程就可以获取A线程所存入的值。 理解了使用场景，很多地方就能想通了
2.ThreadLocal造成内存泄漏的问题我认为有两点：
ThreadLocal原理总结 1.每个Thread维护着一个ThreadLocalMap的引用
2.ThreadLocalMap是ThreadLocal的内部类，用Entry来进行存储
3.调用ThreadLocal的set()方法时，实际上就是往ThreadLocalMap设置值，key是ThreadLocal对象，值是传递进来的对象
4.调用ThreadLocal的get()方法时，实际上就是往ThreadLocalMap获取值，key是ThreadLocal对象
5.ThreadLocal本身并不存储值，它只是作为一个key来让线程从ThreadLocalMap获取value。
这里放出一个程序可以思考一下会输出什么？
答案是
可以debug来看一下他的流程
第一次set，由于Thread中的map还没有被初始化，所以先创建map
因为第一个ThreadLocal已经初始化了map，所以map！=null为true，
到此为止，上面的程序也好理解了，

随笔篇-ThreadLocal原理分析

ThreadLocal 存取值都是借助 ThreadLocalMap 对象去进行存取值，而 ThreadLocalMap 类是定义在 ThreadLocal 类中的一个静态内部类
在再存取值时都是获取当前线程的 ThreadLocalMap 实例，即每个线程都会创建一个 ThreadLocalMap 类型对象，如下:
而 ThreadLocalMap 本质就是一个就是Map类型，在其内部也维护了一个Entry类型对象，如下:
这样就与 HashMap 类似，存储的也是key-value类型数据
从上文的表述中，存储值都是通过 ThreadLocalMap 进行操作，根据源码可知，主要分为三个步骤：
关于每个步骤详细解释如下：
获取当前线程
根据线程实例获取 ThreadLocalMap 类型对象
而获取 ThreadLocalMap 对象则需要传入一个线程对象，查看 getMap 源码可知，其实就是返回了线程对象的 ThreadLocalMap 实例对象
而通过之前的 1.0 章节我们知道，线程对象里面的 threadLocals 对象并没有实例化，只是给了 null 值
实例对象为空则创建 ThreadLocalMap 类型对象
从其源码可知，当实例对象为空的时候,就回去创建 ThreadLocalMap ,创建该类型对象需要传入当前线程对象，以及要存储的值，如下：
查看 createMap 源码可知，就是 new 了一个 ThreadLocalMap 对象
最后将创建好的对象赋值给 线程对象里面的 ThreadLocalMap 实例，源码如下：
如果 map 不为空，则将值存入 ThreadLocalMap 中，key为当前的 ThreadLocal 对象
上述步骤其流程图如下：
ThreadLocal 取值原理与存值原理相似，都是几个固定步骤，如下：
关于这几个步骤详细解释如下
获取当前线程对象
根据线程对象获取 ThreadLocalMap 实例
如果 ThreadLocalMap 实例不为空，则获取值
这里取值并不是直接从Map中获取value，而是根据 this (当前 ThreadLocal )对象取获取 Entry 实体
如果 Entry 实体不为空，则获取Entry的 value ，如下：
如果 ThreadLocalMap 实例为空，则调用 setInitValue 方法
从源码可知，当 ThreadLocalMap 实例为空时，则调用 setInitValue 方法，而该方法
则又是先调用了 initialValue 方法获取value值，也就是存储要初始化存储的值
接下来就又是存值的几个步骤，源码如下：
通过查看 initiaValue 方法可只，该方法为返回 null
关于上述步骤流程图如下：
从上文的表述中知道，往 ThreadLocal 中存值一共有两种方式
当然取值就只通过get方法了，一个线程从始至终就只有一个 ThreadLocalMap 对象
而一个 ThreadLocalMap 可以存储多个 ThreadLocal ,即一个线程可以有多个 ThreadLocal 对象
当然一个 ThreadLocal 对象只能存值一个实例对象，并不能存储多个实例，原因在上文中也进行了阐述
当一个线程启动，并且给创建了一个 ThreadLocal 对象，在堆栈中内存简图如下：
当发生内存泄漏时，有可能时ThreadLocalMap里面的key发生泄漏，也有可能是Map发生value发生泄漏，因此接下来来详细分析一下泄漏原因
通过源码可知，在 ThreadLocalMap 中，可以发现Entry继承了 WeakReference ,且在其构造方法中，将key通过调用父类方法进行了弱引用处理，如下：
从源码知道，也就是 ThreadLocalMap 中的 ThreadLocal 对象一旦回收掉，也就是说key就为null了。
但是value确实一个强引用，即 ThreadLocalMap 中存在 key为null的value,如下：
如果当前线程对象，执行一个耗时操作，长时间不被销毁，也就意味着 ThreadLocalMap 中key为value的数据，永远没法被 GC ，因此可能发生内存泄漏(OOM)
JDK 在设计时已经考虑到这些问题，例如当调用 set() , remove() , rehash() 方法会手动清理key为null的数据，例如查看 set() 方法调用链可知，最后调用了 resize() 方法，如下:
在 resize 方法中，会主动的将key为null的数据也制空，以便防止内存泄漏，如图：
因此如果当 ThreadLocal 发生内存泄漏了，那么肯定是存在了 key 为null的数据，所以在阿里开发规范中， 提到了如果ThreadLocal使用完成，那么应该手动调用一下remove

如何避免threadlocal内存泄露

人觉得，只要你的线程生命周期不长，完全没问题的，JDK7 的 ThreadLocalRandom 也是类似的做法。
如果你觉得不保险，可以加个 remove方法，方法结束的 finally 块里执行 ThreadLocal.remove
　threadlocal里面使用了一个存在弱引用的map,当释放掉threadlocal的强引用以后,map里面的value却没有被回收.而这块value永远不会被访问到了. 所以存在着内存泄露. 最好的做法是将调用threadlocal的remove方法.
　　在threadlocal的生命周期中,都存在这些引用. 看下图: 实线代表强引用,虚线代表弱引用.
　　
　　每个thread中都存在一个map, map的类型是ThreadLocal.ThreadLocalMap. Map中的key为一个threadlocal实例. 这个Map的确使用了弱引用,不过弱引用只是针对key. 每个key都弱引用指向threadlocal. 当把threadlocal实例置为null以后,没有任何强引用指向threadlocal实例,所以threadlocal将会被gc回收. 但是,我们的value却不能回收,因为存在一条从current thread连接过来的强引用. 只有当前thread结束以后, current thread就不会存在栈中,强引用断开, Current Thread, Map, value将全部被GC回收.
　　所以得出一个结论就是只要这个线程对象被gc回收，就不会出现内存泄露，但在threadLocal设为null和线程结束这段时间不会被回收的，就发生了我们认为的内存泄露。其实这是一个对概念理解的不一致，也没什么好争论的。最要命的是线程对象不被回收的情况，这就发生了真正意义上的内存泄露。比如使用线程池的时候，线程结束是不会销毁的，会再次使用的。就可能出现内存泄露。　　
　　PS.Java为了最小化减少内存泄露的可能性和影响，在ThreadLocal的get,set的时候都会清除线程Map里所有key为null的value。所以最怕的情况就是，threadLocal对象设null了，开始发生“内存泄露”，然后使用线程池，这个线程结束，线程放回线程池中不销毁，这个线程一直不被使用，或者分配使用了又不再调用get,set方法，那么这个期间就会发生真正的内存泄露。

ThreadLocal会不会有所谓“内存泄漏”的问题

不会，当一个线程结束，他的引用拷贝将由Thread Local交由垃圾回收机制回收。

如何用Java编写一段代码引发内存泄露

A1：通过以下步骤可以很容易产生内存泄露（程序代码不能访问到某些对象，但是它们仍然保存在内存中）:
应用程序创建一个长时间运行的线程（或者使用线程池，会更快地发生内存泄露）。
线程通过某个类加载器（可以自定义）加载一个类。
该类分配了大块内存（比如new byte[1000000]），在某个静态变量存储一个强引用，然后在ThreadLocal中存储它自身的引用。分配额外的内存new byte[1000000]是可选的(类实例泄露已经足够了)，但是这样会使内存泄露更快。
线程清理自定义的类或者加载该类的类加载器。
重复以上步骤。
由于没有了对类和类加载器的引用，ThreadLocal中的存储就不能被访问到。ThreadLocal持有该对象的引用，它也就持有了这个类及 其类加载器的引用，类加载器持有它所加载的类的所有引用，这样GC无法回收ThreadLocal中存储的内存。在很多JVM的实现中Java类和类加载 器直接分配到permgen区域不执行GC，这样导致了更严重的内存泄露。
这种泄露模式的变种之一就是如果你经常重新部署以任何形式使用了ThreadLocal的应用程序、应用容器（比如Tomcat）会很容易发生内存泄露（由于应用容器使用了如前所述的线程，每次重新部署应用时将使用新的类加载器）。
A2：
静态变量引用对象
class MemorableClass {
static final ArrayList list = new ArrayList(100);
}
调用长字符串的String.intern()
String str=readString(); // read lengthy string any source db,textbox/jsp etc..
// This will place the string in memory pool from which you cant remove
str.intern();
未关闭已打开流(文件，网络等)
try {
BufferedReader br = new BufferedReader(new FileReader(inputFile));
...
...
} catch (Exception e) {
e.printStacktrace();
}
未关闭连接
try {
Connection conn = ConnectionFactory.getConnection();
...
...
} catch (Exception e) {
e.printStacktrace();
}
JVM的GC不可达区域
比如通过native方法分配的内存。
web应用在application范围的对象，应用未重启或者没有显式移除
getServletContext().setAttribute("SOME_MAP", map);
web应用在session范围的对象，未失效或者没有显式移除
session.setAttribute("SOME_MAP", map);
不正确或者不合适的JVM选项
比如IBM JDK的noclassgc阻止了无用类的垃圾回收
A3：如果HashSet未正确实现(或者未实现)hashCode()或者equals(),会导致集合中持续增加“副本”。如果集合不能地忽略掉它应该忽略的元素，它的大小就只能持续增长，而且不能删除这些元素。
如果你想要生成错误的键值对，可以像下面这样做：
class BadKey {
// no hashCode or equals();
public final String key;
public BadKey(String key) { this.key = key; }
}
Map map = System.getProperties();
map.put(new BadKey("key"), "value"); // Memory leak even if your threads die.
A4：除了被遗忘的监听器，静态引用，hashmap中key错误/被修改或者线程阻塞不能结束生命周期等典型内存泄露场景，下面介绍一些不太明显的Java发生内存泄露的情况，主要是线程相关的。
Runtime.addShutdownHook后没有移除，即使使用了removeShutdownHook，由于ThreadGroup类对于未启动线程的bug，它可能不被回收，导致ThreadGroup发生内存泄露。
创建但未启动线程，与上面的情形相同
创建继承了ContextClassLoader和AccessControlContext的线程，ThreadGroup和InheritedThreadLocal的使用，所有这些引用都是潜在的泄露，以及所有被类加载器加载的类和所有静态引用等等。这对ThreadFactory接口作为重要组成元素整个j.u.c.Executor框架(java.util.concurrent)的影响非常明显，很多开发人员没有注意到它潜在的危险。而且很多库都会按照请求启动线程。
ThreadLocal缓存，很多情况下不是好的做法。有很多基于ThreadLocal的简单缓存的实现，但是如果线程在它的期望生命周期外继续运行ContextClassLoader将发生泄露。除非真正必要不要使用ThreadLocal缓存。
当ThreadGroup自身没有线程但是仍然有子线程组时调用ThreadGroup.destroy()。发生内存泄露将导致该线程组不能从它的父线程组移除，不能枚举子线程组。
使用WeakHashMap，value直接(间接)引用key，这是个很难发现的情形。这也适用于继承Weak/SoftReference的类可能持有对被保护对象的强引用。
使用http(s)协议的java.net.URL下载资源。KeepAliveCache在系统ThreadGroup创建新线程，导致当前线程的上下文类加载器内存泄露。没有存活线程时线程在第一次请求时创建，所以很有可能发生泄露。(在Java7中已经修正了，创建线程的代码合理地移除了上下文类加载器。)
使用InflaterInputStream在构造函数(比如PNGImageDecoder)中传递new java.util.zip.Inflater()，不调用inflater的end()。仅仅是new的话非常安全，但如果自己创建该类作为构造函数参数时调用流的close()不能关闭inflater，可能发生内存泄露。这并不是真正的内存泄露因为它会被finalizer释放。但这消耗了很多native内存，导致linux的oom_killer杀掉进程。所以这给我们的教训是：尽可能早地释放native资源。
java.util.zip.Deflater也一样，它的情况更加严重。好的地方可能是很少用到Deflater。如果自己创建了Deflater或者Inflater记住必须调用end()。

Android面试 Handler机制

Handler就是解决线程与线程间的通信。 当我们在子线程处理耗时操作，耗时操作完成后我们需要更新UI的时候，这就是需要使用Handler来处理了，因为子线程不能更 新UI，Handler能让我们容易的把任务切换回来它所在的线程。 消息处理机制本质：一个线程开启循环模式持续监听并依次处理其他线程给它发的消息。
一个线程可以有多个Handler，通过new Handler的方式创建。
一个线程只能有一个Looper，通过Looper.perpare方法会创建一个Looper保存在ThreadLocal中，每个线程都有一个LocalThreadMap，会将Looper保存在对应线程中的LocalThreadMap，key为ThreadLocal，value为Looper。
内部类持有外部类的对象，handler持有activity的对象，当页面activity关闭时，handler还在发送消息，handler持有activity的对象，导致handler不能及时被回收，所以造成内存泄漏。
因为当handler发送消息时，会有耗时操作，并且会利用线程中的looper和messageQueue进行消息发送，looper和messageQueue的生命周期是很长的，和application一样，所以handler不容易被销毁，所以造成内存泄漏。
解决方案有：
可以在子线程中创建Handler，我们需要调用Looper.perpare和Looper.loop方法。或者通过获取主线程的looper来创建Handler。
应该调用Looper的quit方法，因为可以将looper中的messageQueue里的message都移除掉，并且将内存释放。
通过synchronized锁机制保证线程安全。
Message.obtain来创建Message。这样会复用之前的Message的内存，不会频繁的创建对象，导致内存抖动。
点击按钮的时候会发送消息到Handler，但是为了保证优先执行，会加一个标记异步，同时会发送一个target为null的消息，这样在使用消息队列的next获取消息的时候，如果发现消息的target为null，那么会遍历消息队列将有异步标记的消息获取出来优先执行，执行完之后会将target为null的消息移除。(同步屏障)
更多内容戳这里（整理好的各种文集）

图解分析ThreadLocal的原理与应用场景

ThreadLocal这个类想必大家都不陌生，直接翻译为 线程本地（变量） ，我们经常会使用到它来保存一些 线程隔离的 、 全局的 变量信息。使用ThreadLocal维护变量时，每个线程都会获得该线程独享一份变量副本。 ThreadLocal比较像是DNF中的一个地下城副本，而每个线程像是每个进入DNF副本中的玩家。各个线程进入副本后都是比较隔离的，不会互相干扰，这一特性在多线程的某些场景下十分适用。

ThreadLocal将变量的使用范围恰当的保存到了全局变量和局部变量之间。
笔者经常使用ThreadLocal的场景有：
ThreadLocal实现结构以及执行的过程如下图所示。
ThreadLocal的几个关键词。
如前文所述，ThreadLocalMap其实是一个ThreadLocal --> value的映射，具体的实现关系如下图

因此，必须在使用了ThreadLocal的线程执行完后finally中调用 threadLocal.remove() ，或者如果 ThreadLocal

的话则调用 threadlocal.get().remove() 清空HashMap

在ThreadLocal的使用中，我们经常会需要创建子线程，希望子线程能够继承父线程的ThreadLocal，还是以traceid的使用场景为例，我们创建了子线程来并发处理耗时的逻辑，并且希望子线程中也能如实的打印当前请求的traceid，但是 普通的ThreadLocal在创建新线程后信息会完全丢失 ，笔者曾经在这里踩到过坑。

所以就需要一种方案来复制ThreadLocal到子线程：

[1] ThreadLocal-hash冲突与内存泄漏 [2] ThreadLocal面试攻略：吃透它的每一个细节和设计原理 [3] 面试官：小伙子，听说你看过ThreadLocal源码？（万字图文深度解析ThreadLocal）