目錄
一.介紹
二.問題提出
2.1內存原理圖
2.2幾個問題
三.回答問題
3.1為什麼會出現內存泄漏
3.2若Entry使用弱引用
3.3弱引用配合自動回收
四.總結
一.介紹
之前使用ThreadLocal的時候，就聽過ThreadLocal怎麼怎麼的可能會出現內存泄漏，具體原因也沒去深究，就是一種不清不楚的狀態。最近在看JDK的源碼，其中就包含ThreadLocal，在對ThreadLocal的使用場景介紹以及源碼的分析后，對於ThreadLocal中可能存在的內存泄漏問題也搞清楚了，所以這裏專門寫一篇博客分析一下。
在分析內存泄漏之前，先了解2個概念，就是內存泄漏和內存溢出：
內存溢出（memory overflow）：是指不能申請到足夠的內存進行使用，就會發生內存溢出，比如出現的OOM（Out Of Memory）
內存泄漏（memory lack）：內存泄露是指在程序中已經動態分配的堆內存由於某種原因未釋放或者無法釋放（已經沒有用處了，但是沒有釋放），造成系統內存的浪費，這種現象叫“內存泄露”。
當內存泄露到達一定規模后，造成系統能申請的內存較少，甚至無法申請內存，最終導致內存溢出，所以內存泄露是導致內存溢出的一個原因。
二.問題提出
2.1內存原理圖
下圖是程序運行中的內存分布圖，簡要介紹一下這種圖：當前線程有一個threadLocals屬性（ThreadLocalMap屬性），該map的底層是數組，每個數組元素時Entry類型，Entry類型的key是ThreadLocal類型（也就是創建的ThreadLocal對象），而value是則是ThreadLocal.set()方法設置的value。
需要注意的是ThreadLocalMap的Entry，繼承自弱引用，定義如下，關於Java的引用介紹，可以參考：Java-強引用、軟引用、弱引用、虛引用
/**
* ThreadLocalMap中存放的元素類型，繼承了弱引用類
*/
static class Entry extends WeakReference<ThreadLocal<?>> {
// key對應的value，注意key是ThreadLocal類型
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
2.2問題提出
在看了上面ThreadLocal和ThreadLocalMap相關的內存分佈以及關聯后，提出這樣幾個問題：
1.ThreadLocal為什麼會出現內存溢出？
2.Entry的key為什麼要用弱引用？
3.使用弱引用是否就能解決內存溢出？
為了回答上面這3個問題，我寫了一段代碼，後面根據這段代碼進行分析：
public void step1() {
// some action
step2();
step3();
// other action
}
// 在stepX中都會創建threadLocal對象
public void step2() {
ThreadLocal<String> tl = new ThreadLocal<>();
tl.set("this is value");
}
public void step3() {
ThreadLocal<Integer> tl = new ThreadLocal<>();
tl.set(99);
}
在step1中會調用step2和step3，step2和step3都會創建ThreadLocal對象，當step2和step3執行完畢后，其中的棧內存中ThreadLocal引用就會被清除。
三.回答問題
現在針對這個圖，一步一步的分析問題，中途會得出一些臨時的結論，但是最終的結論才是正確的。
3.1為什麼會出現內存泄露
現在有2點假設，本小節的分析都是基於這兩個假設之上的：
1.Entry的key使用強引用，key對ThreadLocal對象使用強引用，也就是上面圖中連線5是強引用（key強引用ThreadLocal對象）；
2.ThreadLocalMap中不會對過期的Entry進行清理。
上面代碼中，如果ThreadLocalMap的key使用強引用，那麼即使棧內存的ThreadLocal引用被清除，但是堆中的ThreadLocal對象卻並不會被清除，這是因為ThreadLocalMap中Entry的key對ThreadLocal對象是強引用。
如果當前線程不結束，那麼堆中的ThreadLocal對象將會一直存在，對應的內存就不會被回收，與之關聯的Entry也不會被回收（Entry對應的value也不會被回收），當這種情況出現數量比較多的時候，未釋放的內存就會上升，就可能出現內存泄漏的問題。
上面的結論是暫時的，有前提假設！！！最終結論還需要看後面分析。
3.2若Entry使用弱引用
仍舊有1個假設，就是ThreadLocalMap中不會對過期的Entry進行清理，陳舊的Entry是指Entry的key為null。
按照源碼，Entry繼承弱引用，其Key對ThreadLocal是弱引用，也就是上圖中連線5是弱引用，連線6仍為強引用。
同樣以上面代碼為例，step2和step3創建了ThreadLocal對象，step2和step3執行完后，棧中的ThreadLocal引用被清除了；由於堆內存中ThreadLocalMap的Entry key弱引用ThreadLocal對象，根據垃圾收集器對弱引用對象的處理：
當垃圾收集器工作時，無論當前內存是否足夠，都會回收掉只被弱引用關聯的對象。
此時堆中ThreadLocal對象會被gc回收（因為現在沒有對ThreadLocal的強引用，只有一個弱引用ThreadLocal對象），Entry的key為null，但是value不為null，且value也是強引用（連線6），所以Entry仍舊不能回收，只能釋放ThreadLocal的內存，仍舊可能導致內存泄漏。
在沒有自動清理陳舊Entry的前提下，即使Entry使用弱引用，仍可能出現內存泄漏。
3.3弱引用配合自動回收
通過3.2的分析，其實只要陳舊的Entry能自動被回收，就能解決內存泄漏的問題，其實JDK就是這麼做的。
如果看過源碼，就知道，ThreadLocalMap底層使用數組來保存元素，使用“線性探測法”來解決hash衝突，關於線性探測法的介紹可以查看：利用線性探測法解決hash衝突
在每次調用ThreadLocal類的get、set、remove這些方法的時候，內部其實都是對ThreadLocalMap進行操作，對應ThreadLocalMap的get、set、remove操作。
重點來了！重點來了！重點來了！
ThreadLocalMap的每次get、set、remove，都會清理過期的Entry，下面以get操作解釋，其他操作也是一個意思，大致如下：
1.ThreadLocalMap底層用數組保存元素，當get一個Entry時，根據key的hash值（非hashCode）計算出該Entry應該出在什麼位置；
2.計算出的位置可能會有衝突，比如預期位置是position=5，但是position=5的位置已經有其他Entry了；
3.出現衝突后，會使用線性探測法，找position=6位置上的Entry是否匹配（匹配是指hash相同），如果匹配，則返回position=6的Entry。
4.在這個過程中，如果position=5位置上的Entry已經是陳舊的Entry（Entry的key為null），此時position=5的key就應該被清理；
5.光清理position=5的Entry還不夠，為了保證線性探測法的規則，需要判斷數組中的其他元素是否需要調整位置（如果需要，則調整位置），在這個過程中，也會進行清理陳舊Entry的操作。
上面這5個步驟就保證了每次get都會清理數組中（map）的陳舊Entry，清理一個陳舊的Entry，就是下面這三行代碼：
Entry.value = null; // 將Entry的value設為null table[index] = null;// 將數組中該Entry的位置設置null size--; // map的size減一
對於ThreadLocal的set、remove也類似這個原理。
有了自動回收陳舊Entry的操作，需要注意的是，在這個時候，key使用弱引用就是至關重要的一點！！！
因為key使用弱引用后，當弱引用的ThreadLocal對象被會回收后，該key的引用為null，則該Entry在下一次get、set、remove的時候就才會被清理，從未避免內存泄漏的問題。
四.總結
在上面的分析中，看到ThreadLocal基本不會出現內存泄漏的問題了，因為ThreadLocalMap中會在get、set、remove的時候清理陳舊的Entry，與Entry的key使用弱引用密不可分。
當然我們也可以在代碼中手動調用ThreadLocal的remove方法進行清除map中key為該threadLocal對象的Entry，同時清理過期的Entry。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線
※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整
※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!
※教你寫出一流的銷售文案?
※超省錢租車方案
