ThreadLocal原理

ゝ一世哀愁。 2023-10-04 23:34 11阅读 0赞

### ThreadLocal是什么？ ###

ThreadLocal是线程本地存储机制，可以将数据缓存在线程内部。ThreadLocal存储的变量在线程内共享的，在线程间又是隔离的。

### ThreadLocal原理？ ###

ThreadLocal的底层是ThreadLocalMap，ThreadLocalMap存储的键值对，key就是ThreadLocal实例，value就是要缓存的值。  
每个Thread都有一个ThreadLocalMap，当创建ThreadLocal，set数据时调用的是ThreadLocalMap的set方法，set方法将ThreadLocal对象和缓存值存入Map。  
也就是说，想要存入的ThreadLocal中的数据实际上并没有存到ThreadLocal对象中去，而是以这个ThreadLocal实例作为key存到了**当前线程中的ThreadLocalMap中**去了，获取ThreadLocal的值时同样也是这个道理。这也就是为什么ThreadLocal可以实现线程之间隔离的原因了。

源码：

/**
         * Sets the current thread's copy of this thread-local variable
         * to the specified value.  Most subclasses will have no need to
         * override this method, relying solely on the {@link #initialValue}
         * method to set the values of thread-locals.
         *
         * @param value the value to be stored in the current thread's copy of
         *        this thread-local.
         */
        public void set(T value) {
        
            Thread t = Thread.currentThread();
            ThreadLocalMap map = getMap(t);
            if (map != null)
                map.set(this, value);
            else
                createMap(t, value);
        }

### ThreadLocal的内存泄露问题 ###

在每一个线程Thread对象中，都维护了一个ThreadLocalMap对象。ThreadLocalMap中又维护了一个k v 形式的Entry对象，key指向了当前ThreadLocal对象，value就是我们实际在ThreadLocal中存储的值。Entry中的key存放是ThreadLocal的弱引用。

### 内存泄漏原因 ###

因为ThreadLocalMap的key对它的引用是弱引用，将会在下一次gc被回收，那就会出现key变成null，如果这时value外部也没有强引用指向它，那么value就永远也访问不到了，按理也应该被GC回收，但是由于ThreadLocalMap.Entry对象还在强引用value，导致value无法被回收，这时「内存泄漏」就发生了，value成了一个永远也无法被访问，但是又无法被回收的对象。

### 为什么使用弱引用？ ###

弱引用的作用就是当出现GC的时候会回收这些弱引用的对象，如果有些业务不是定义的全局的静态变量而是局部的变量，例如：通过ThreadLocal保存一些在整个线程中全局都可以使用的变量，减少方法与方法调用的参数传递。此时当一个任务执行完成之后，可以将ThreadLocal设置成为null，局部变量的强引用就会失效，存在Map中的Entry的key只有弱引用，如果不进行清理的话，则会出现内存泄漏的问题，此时出现GC的时候就会回收掉ThreadLocal对象，也就是说ThreadLocal是尽量的去避免内存泄漏的问题。但是解决不了根本的问题，所以需要开发人员手动去调用remove()方法才能够彻底解决内存泄漏的问题。

那么为什么 key 要用弱引用呢  
事实上，在 ThreadLocalMap 中的set/getEntry 方法中，会对 key 为 null（也即是 ThreadLocal 为 null ）进行判断，如果为 null 的话，那么会把 value 置为 null 的．这就意味着使用完 ThreadLocal , CurrentThread 依然运行的前提下．就算忘记调用 remove 方法，弱引用比强引用可以多一层保障：弱引用的 ThreadLocal 会被回收．对应value在下一次 ThreadLocaIMap 调用 set/get/remove 中的任一方法的时候会被清除，从而避免内存泄漏．

为什么要这么设计呢? 不妨这样思考，假设key也用强引用指向当前ThreadLocal的话，那么如果我这时候写 t1 = null ，按理说下次GC时，应该要把堆内存的new ThreadLocal（） 这个对象进行回收才对，但此时我的key如果设计成强引用，显然GC无法对它进行回收，因为key还强引用指向它。这就会造成内存泄漏，所以ThreadLocal存值时，key采用弱引用。  
key使用弱引用的特点就很明显了（只要是GC回收，不管内存够不够，都会回收弱引用指向的对象），当我写 t1 = null ， 下次GC回收时，就可以将new ThreadLocal（） 这个对象会被回收掉。  
内存泄漏不单单只是上面的问题，上面所述的内存泄漏问题不需要关心，因为源码已经设计好并解决了。  
现在继续思考：既然key是虚引用指向，当写 t1 = null ，下次进行GC回收时，这个堆中的ThreadLocal对象会被回收掉，那么key的引用就没有了，key会变成null，那么值的内容还存在着，就会产生内存泄漏！

### 内存泄漏原因 ###

解决办法：  
1:将ThreadLocal设置为空之前，执行remove（）方法，会将key为空的键值对清空

2：尽量将ThreadLocal设置成static
    
                  3: 非必要尽量不要在ThreadLocal中放大对象