ThreadLocal可能引起的内存泄露

合集 - 并发(22)

1.BIO、NIO、AIO的区别2022-05-312.Controller是线程安全吗2022-06-013.为什么多线程下会有线程安全问题2023-07-234.volatile为什么没有原子性?2018-06-255.JVM的四种内存屏障2022-05-266.synchronized关键字原理2018-06-247.synchronized 锁升级 锁降级2022-05-308.自旋锁、阻塞锁、可重入锁使用解析2022-06-019.线程间实现通信的几种方式2023-08-2510.ThreadPoolExecutor线程池参数设置技巧2022-05-3011.关于线程同步（7种同步方式）2018-06-04

12.ThreadLocal可能引起的内存泄露2022-05-31

13.乐观锁的一种实现方式——CAS2018-04-2714.AtomicInteger源码解析2018-04-2215.ReentrantLock源码解析1--获得非公平锁与公平锁lock()2018-04-2416.ReentrantLock源码解析2--释放锁unlock()2018-04-2417.ReentrantLock源码解析3--优先响应中断的lockInterruptibly2018-04-2518.ReentrantLock总结2018-04-2519.ArrayBlockingQueue源码解析2018-04-2520.LinkedBlockingQueue源码解析2018-04-2221.Timer / TimerTask 源码解析2018-10-0922.Delay延迟队列2018-08-05

收起

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方法，那么这个期间就会发生真正的内存泄露。