Java ThreadLocal的內存泄漏問題

ThreadLocal提供了線程獨有的局部變量，能夠在整個線程存活的過程當中隨時取用，極大地方便了一些邏輯的實現。常見的ThreadLocal用法有：

- 存儲單個線程上下文信息。好比存儲id等；

- 使變量線程安全。變量既然成爲了每一個線程內部的局部變量，天然就不會存在併發問題了；

- 減小參數傳遞。好比作一個trace工具，可以輸出工程從開始到結束的整個一次處理過程當中全部的信息，從而方便debug。因爲須要在工程各處隨時取用，可放入ThreadLocal。

 

原理

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}。（注：實際是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()); } } ------------------------------- | TL_INT -> 6 | | TL_STRING -> "Hello, world"|

對於一個普通的map，取其中某個key對應的值分兩步：

1. 找到這個map；

2. 在map中，給出key，獲得value。

 

想取出咱們存放在當前線程裏的map裏的值一樣須要這兩步。可是，咱們不須要告訴jvm map在哪兒，由於jvm知道當前線程，也知道其局部變量map。因此最終的get操做只須要知道key就好了：int localInt = TL_INT.get();。

看起來有些奇怪，不一樣於常規的map的get操做的接口的樣子。

 

爲何key使用弱引用

不妨反過來想一想，若是使用強引用，當ThreadLocal對象（假設爲ThreadLocal@123456）的引用（即：TL_INT，是一個強引用，指向ThreadLocal@123456）被回收了，ThreadLocalMap自己依然還持有ThreadLocal@123456的強引用，若是沒有手動刪除這個key，則ThreadLocal@123456不會被回收，因此只要當前線程不消亡，ThreadLocalMap引用的那些對象就不會被回收，能夠認爲這致使Entry內存泄漏。

 

那使用弱引用的好處呢？

若是使用弱引用，那指向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，會從新調用初始化方法。）

 

內存泄露

總結一下內存泄露（本該回收的無用對象沒有獲得回收）的緣由：

1 弱引用必定程度上回收了無用對象，但前提是開發者手動清理掉ThreadLocal對象的強引用（如TL_INT）。只要線程一直不死，ThreadLocalMap的key-value一直在漲。

解決方法：當某個ThreadLocal變量（好比：TL_INT）再也不使用時，記得TL_INT.remove()，刪除該key。

2 在上例中，ThreadLocalDemo持有static的ThreadLocal類型：TL_INT，致使TL_INT的生命週期跟ThreadLocalDemo類的生命週期同樣長。意味着TL_INT不會被回收，弱引用形同虛設，因此當前線程沒法經過ThreadLocalMap的防禦措施清除TL_INT所對應的value（Integer）的強引用。一般，咱們須要保證做爲key的TL_INT類型可以被全局訪問到，同時也必須保證其爲單例，所以，在一個類中將其設爲static類型便成爲了慣用作法。卻不知這樣增長了ThreadLocal的使用風險。

ThreadLocal 最佳實踐

綜合上面的分析，咱們能夠理解ThreadLocal內存泄漏的來龍去脈，那麼怎麼避免內存泄漏呢？

每次使用完ThreadLocal，都調用它的remove()方法，清除數據。在使用線程池的狀況下，沒有及時清理ThreadLocal，不只是內存泄漏的問題，更嚴重的是可能致使業務邏輯出現問題。因此，使用ThreadLocal就跟加鎖完要解鎖同樣，用完就清理。

 

線程池

使用了線程池，能夠達到「線程複用」的效果。可是歸還線程以前記得清除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; }