ThreadLocal原理及内存泄露预防
参阅：http://www.importnew.com/22039.htmlhtml
前言
ThreadLocal提供了线程独有的局部变量，能够在整个线程存活的过程当中随时取用，极大地方便了一些逻辑的实现。常见的ThreadLocal用法有：
- 存储单个线程上下文信息。好比存储id等；
- 使变量线程安全。变量既然成为了每一个线程内部的局部变量，天然就不会存在并发问题了；
- 减小参数传递。好比作一个trace工具，可以输出工程从开始到结束的整个一次处理过程当中全部的信息，从而方便debug。因为须要在工程各处随时取用，可放入ThreadLocal。java
原理
ThreadLocal里类型的变量，实际上是放入了当前Thread里。每一个Thread都有一个{@link Thread#threadLocals}，它是一个map：{@link java.lang.ThreadLocal.ThreadLocalMap}。这个map的entry是{@link java.lang.ThreadLocal.ThreadLocalMap.Entry}，具体的key和value类型分别是{@link ThreadLocal}和 {@link Object}。web
（注：实际是ThreadLocal的弱引用WeakReference<ThreadLocal<?>>，但能够先简单理解为ThreadLocal。）缓存
当设置一个ThreadLocal变量时，这个map里就多了一对ThreadLocal -> Object的映射。安全
经过一个简单程序来讲明上图：并发
package example.concurrency.tl;
/** * @author liuhaibo on 2018/05/23 */
public class ThreadLocalDemo {
private static final ThreadLocal<Integer> TL_INT = ThreadLocal.withInitial(() -> 6);
private static final ThreadLocal<String> TL_STRING = ThreadLocal.withInitial(() -> "Hello, world");
public static void main(String... args) {
// 6
System.out.println(TL_INT.get());
TL_INT.set(TL_INT.get() + 1);
// 7
System.out.println(TL_INT.get());
TL_INT.remove();
// 会从新初始化该value，6
System.out.println(TL_INT.get());
}
}
- Stack-ThreadLocalRef：TL_INT;
- Stack-CurrentThreadRef： 当前线程在栈中的引用；
- Heap-ThreadLocal：TL_INT引用所对应的ThreadLocal实例；
- Heap-CurrentThread：当前线程实例；
- Heap-Map：当前线程内部的threadLocals变量所对应的map实例；
- Heap-Entry：上述map的entry；
- Heap-Entry-Key：上述entry的键的弱引用；
- Heap-Entry-Value：上述entry的值的强引用；
对于上述程序，实际上咱们在当前线程的threadlocals这个map里放了以下内容：app
| TL_INT -> 6 |
| TL_STRING -> "Hello, world"|
对于一个普通的map，取其中某个key对应的值分两步：
1. 找到这个map；
2. 在map中，给出key，获得value。jvm
想取出咱们存放在当前线程里的map里的值一样须要这两步。可是，咱们不须要告诉jvm map在哪儿，由于jvm知道当前线程，也知道其局部变量map。因此最终的get操做只须要知道key就好了：int localInt = TL_INT.get();。
看起来有些奇怪，不一样于常规的map的get操做的接口的样子。ide
为何key使用弱引用
不妨反过来想一想，若是使用强引用，当ThreadLocal对象（假设为ThreadLocal@123456）的引用（即：TL_INT，是一个强引用，指向ThreadLocal@123456）被回收了，ThreadLocalMap自己依然还持有ThreadLocal@123456的强引用，若是没有手动删除这个key，则ThreadLocal@123456不会被回收，因此只要当前线程不消亡，ThreadLocalMap引用的那些对象就不会被回收，能够认为这致使Entry内存泄漏。svg
那使用弱引用的好处呢？
若是使用弱引用，那指向ThreadLocal@123456对象的引用就两个：TL_INT强引用，和ThreadLocalMap中Entry的弱引用。一旦TL_INT被回收，则指向ThreadLocal@123456的就只有弱引用了，在下次gc的时候，这个ThreadLocal@123456就会被回收。
那么问题来了，ThreadLocal@123456对象只是做为ThreadLocalMap的一个key而存在的，如今它被回收了，可是它对应的value并无被回收，内存泄露依然存在！并且key被删了以后，变成了null，value更是没法被访问到了！针对这一问题，ThreadLocalMap类的设计自己已经有了这一问题的解决方案，那就是在每次get()/set()/remove()ThreadLocalMap中的值的时候，会自动清理key为null的value。如此一来，value也能被回收了。
既然对key使用弱引用，能使key自动回收，那为何不对value使用弱引用？答案显而易见，假设往ThreadLocalMap里存了一个value，gc事后value便消失了，那就没法使用ThreadLocalMap来达到存储全线程变量的效果了。（可是再次访问该key的时候，依然能取到value，此时取得的value是该value的初始值。即在删除以后，若是再次访问，取到null，会从新调用初始化方法。）
内存泄露
总结一下内存泄露（本该回收的无用对象没有获得回收）的缘由：
- 弱引用必定程度上回收了无用对象，但前提是开发者手动清理掉ThreadLocal对象的强引用（如TL_INT）。只要线程一直不死，ThreadLocalMap的key-value一直在涨。
解决方法：当某个ThreadLocal变量（好比：TL_INT）再也不使用时，记得TL_INT.remove()，删除该key。
在上例中，ThreadLocalDemo持有static的ThreadLocal类型：TL_INT，致使TL_INT的生命周期跟ThreadLocalDemo类的生命周期同样长。意味着TL_INT不会被回收，弱引用形同虚设，因此当前线程没法经过ThreadLocalMap的防御措施清除TL_INT所对应的value（Integer）的强引用。
一般，咱们须要保证做为key的TL_INT类型可以被全局访问到，同时也必须保证其为单例，所以，在一个类中将其设为static类型便成为了惯用作法。
线程池
使用了线程池，能够达到“线程复用”的效果。可是归还线程以前记得清除ThreadLocalMap，要否则再取出该线程的时候，ThreadLocal变量还会存在。这就不只仅是内存泄露的问题了，整个业务逻辑均可能会出错。
解决方法参考：
/**
* Method invoked upon completion of execution of the given Runnable.
* This method is invoked by the thread that executed the task. If
* non-null, the Throwable is the uncaught {@code RuntimeException}
* or {@code Error} that caused execution to terminate abruptly.
*
* <p>This implementation does nothing, but may be customized in
* subclasses. Note: To properly nest multiple overridings, subclasses
* should generally invoke {@code super.afterExecute} at the
* beginning of this method.
*
... some deleted ...
*
* @param r the runnable that has completed
* @param t the exception that caused termination, or null if
* execution completed normally
*/
protected void afterExecute(Runnable r, Throwable t) { }
override {@link ThreadPoolExecutor#afterExecute(r, t)}方法，对ThreadLocalMap进行清理，好比：
protected void afterExecute(Runnable r, Throwable t) {
// you need to set this field via reflection.
Thread.currentThread().threadLocals = null;
}
参考：https://stackoverflow.com/a/30328722/7676237
因此ThreadLocal最好仍是不要和线程池一块儿使用，就没这么多问题了:D
附：强引用-软引用-弱引用
- 强引用：普通的引用，强引用指向的对象不会被回收；
- 软引用：仅有软引用指向的对象，只有发生gc且内存不足，才会被回收；
- 弱引用：仅有弱引用指向的对象，只要发生gc就会被回收。
看一个例子就明白强引用、软引用、弱引用的区别：
package example.reference;
import java.lang.ref.SoftReference;
import java.lang.ref.WeakReference;
/** * @author liuhaibo on 2018/03/06 */
public class WeakRefDemo {
public static void main(String... args) {
// all these objects have a strong reference
Object a = new Object();
Object b = new Object();
Object c = new Object();
// other references to these objects
Object strongA = a;
SoftReference<Object> softB = new SoftReference<>(b);
WeakReference<Object> weakC = new WeakReference<>(c);
// free the former strong references to these objects:
// there is still a strong reference(strongA) to the first object
a = null;
// only a soft reference(softB) refers to the second object
b = null;
// only a weak reference(weakC) refers to the third object
c = null;
System.out.println("Before gc...");
System.out.println(String.format("strongA = %s, softB = %s, weakC = %s", strongA, softB.get(), weakC.get()));
System.out.println("Run GC...");
System.gc();
// object with only soft reference will be cleaned only if memory is not enough: 用来作缓存很不错
// object with only weak reference will be cleaned after a gc operation:
System.out.println("After gc...");
System.out.println(String.format("strongA = %s, softB = %s, weakC = %s", strongA, softB.get(), weakC.get()));
}
}
Output：
Before gc...
strongA = java.lang.Object@3af49f1c, softB = java.lang.Object@19469ea2, weakC = java.lang.Object@13221655
Run GC...
After gc...
strongA = java.lang.Object@3af49f1c, softB = java.lang.Object@19469ea2, weakC = null