ThreadLocal的作用是提供线程内的数据存储。在Android里面Handler的Looper就是利用ThreadLocal来存储的,下面代码片段来自Android源码Looper.java，主线程的Looper就是存储在这个sThreadLocal静态变量里面
public final class Looper {
private static final String TAG = "Looper";
// sThreadLocal.get() will return null unless you've called prepare().
@UnsupportedAppUsage
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
@UnsupportedAppUsage
private static Looper sMainLooper; // guarded by Looper.class
private static Observer sObserver;
@UnsupportedAppUsage
final MessageQueue mQueue;
final Thread mThread;
@UnsupportedAppUsage
private Printer mLogging;
private long mTraceTag;
...
}
回到刚才的话题ThreadLocal会发生内存泄露吗？要想解答这个问题首先要弄清楚以下这两个问题：
- ThreadLocal实现原理
- ThreadLocal在什么情况下回内存泄露
ThreadLocal实现原理
ThreadLocal最重要的两个方法set和get方法
- 我们首先从他的
set方法入手
public void set(T value) {
//获取当前线程对象
Thread t = Thread.currentThread();
// 根据当前线程对象获取一个ThreadLocalMap（相当于Map容器）
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value); //这里是以this（其实就是ThreadLocal对象）为key，和传进来的泛型对象value组成键值对的形式存储起来
else
createMap(t, value);// map为空则为当前线程创建一个ThreadLocalMap然后以ThreadLocal为key和传进来的value组成键值对保存起来
}
//初始化Thread中的threadLocals并保存第一次要存的值
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
最终的取值和初始化存值都在ThreadLocalMap结构里面，等下再分析这个对象。
-
再看它的
get方法public T get() { //获取当前线程对象 Thread t = Thread.currentThread(); //获取当前线程对象的ThreadLocalMap ThreadLocalMap map = getMap(t); if (map != null) { //根据当前ThreadLocal（key）获取存储的数据的Entry，Entry中的value就是存储的数据了 ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } //若没有该变量，返回setInitialValue() return setInitialValue(); }get方法代码不多，主要流程是获取当前线程对象，获取线程的
ThreadLocalMap，如果ThreadLocalMap中有值则返回，没有则调用setInitialValue初始化并返回。 -
从
set和get这两个主要的方法中我们得知ThreadLocal的实现是这样的：每个Thread维护一个ThreadLocalMap映射表，这个映射表的 key 是ThreadLocal实例本身，value 是真正需要存储的 Object。那我们来看下ThreadLocalMap里面到底是怎么存储对象的。
图片来自Java识堂
也就是说ThreadLocal本身并不存储值，它只是作为一个key来让线程从 ThreadLocalMap 获取 value。值得注意的是图中的虚线，表示ThreadLocalMap是使用ThreadLocal的弱引用作为 Key 的，弱引用的对象在 GC 时会被回收。参看ThreadLocalMap类代码，真正管理的是一个Entry数组,Entry继承了WeakReference。
static class ThreadLocalMap {
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
private static final int INITIAL_CAPACITY = 16;
private Entry[] table;
private int size = 0;
private int threshold; // Default to 0
...
}
ThreadLocal为什么会内存泄漏
ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用来引用它，那么系统 GC 的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏。
其实，ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。
但是这些被动的预防措施并不能保证不会内存泄漏：
- 使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能导致的内存泄漏（参考ThreadLocal 内存泄露的实例分析）。
- 分配使用了ThreadLocal又不再调用get(),set(),remove()方法，那么就会导致内存泄漏。
比较两种情况，我们可以发现：由于ThreadLocalMap的生命周期跟Thread一样长，如果都没有手动删除对应key，都会导致内存泄漏，但是使用弱引用可以多一层保障：弱引用ThreadLocal不会内存泄漏，对应的value在下一次ThreadLocalMap调用set,get,remove的时候会被清除。
因此，ThreadLocal内存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一样长，特别是使用线程池的时候，核心线程会回收利用一直存活，如果没有手动删除对应key就会导致内存泄漏，而不是因为弱引用。
ThreadLocal 最佳实践
综合上面的分析，我们可以理解ThreadLocal内存泄漏的前因后果，那么怎么避免内存泄漏呢？
- 每次使用完ThreadLocal，都调用它的remove()方法，清除数据。 在使用线程池的情况下，没有及时清理ThreadLocal，不仅是内存泄漏的问题，更严重的是可能导致业务逻辑出现问题。所以，使用ThreadLocal就跟加锁完要解锁一样，用完就清理。
