1、首先看下ThreadLocal的原理圖：
在ThreadLocal的生命周期中，都存在這些引用。
其中，實線代表強引用，虛線代表弱引用；
2、ThreadLocal的實現：每個Thread維護一個ThreadLocalMap映射表，這個映射表的key是ThreadLocal實例本身，value是真正需要存儲的Object;
3、也就是說ThreadLocal本身不存儲值，它只是作為一個key來讓線程從ThreadLocalMap獲取value，值得注意的是圖中的虛線，表示ThreadLocalMap是使用ThreadLocal的弱引用作為key，其在GC時會被回收；
4、ThreadLocalMap使用ThreadLocal的弱引用作為key，如果一個ThreadLocal沒有外部強引用來引用它，那么系統 GC 的時候，這個ThreadLocal勢必會被回收，這樣一來，ThreadLocalMap中就會出現key為null的Entry，就沒有辦法訪問這些key為null的Entry的value，如果當前線程再遲遲不結束的話，這些key為null的Entry的value就會一直存在一條強引用鏈：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永遠無法回收，造成內存泄漏。
5、總的來說就是，ThreadLocal里面使用了一個存在弱引用的map, map的類型是ThreadLocal.ThreadLocalMap. Map中的key為一個threadlocal實例。這個Map的確使用了弱引用，不過弱引用只是針對key。每個key都弱引用指向threadlocal。 當把threadlocal實例置為null以后，沒有任何強引用指向threadlocal實例，所以threadlocal將會被gc回收。
但是，我們的value卻不能回收，而這塊value永遠不會被訪問到了，所以存在着內存泄露。因為存在一條從current thread連接過來的強引用。只有當前thread結束以后，current thread就不會存在棧中，強引用斷開，Current Thread、Map value將全部被GC回收。最好的做法是將調用threadlocal的remove方法，這也是等會后邊要說的。
6、其實，ThreadLocalMap的設計中已經考慮到這種情況，也加上了一些防護措施：在ThreadLocal的get(),set(),remove()的時候都會清除線程ThreadLocalMap里所有key為null的value。這一點在上一節中也講到過！
7、但是這些被動的預防措施並不能保證不會內存泄漏：
a、使用static的ThreadLocal，延長ThreadLocal的生命周期，可能導致內存泄漏；
b、分配只用了ThreadLocal又不再調用get()、set()、remove()方法，那么可能導致內存泄漏，因為這塊內存會一直存在；
以下是源碼：
/**
* The entries in this hash map extend WeakReference, using
* its main ref field as the key (which is always a
* ThreadLocal object). Note that null keys (i.e. entry.get()
* == null) mean that the key is no longer referenced, so the
* entry can be expunged from table. Such entries are referred to
* as "stale entries" in the code that follows.
*/
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}