ThreadLocal注意事項

在使用了執行緒池(如executor)的情況下，那麼即使父執行緒已經結束，子執行緒依然存在並被池化。這樣，執行緒池中的執行緒在下一次請求被執行的時候，threadlocal物件的get()方法返回的將不是當前執行緒中設定的變數，因為池中的「子執行緒」根本不是當前執行緒建立的，當前執行緒設定的 threadlocal變數也就無法傳遞給執行緒池中的執行緒。因此，必須將外部執行緒中的threadlocal變數顯式地傳遞給執行緒池中的執行緒。

關於threadlocal的記憶體洩露問題：

public class threadlocaltest 
public static class mythreadlocal extends threadlocal 
}public static class my50mb }}

執行結果：

full gc my threadlocal 1 mb finalized.

timeunit.seconds.sleep(1)是為了給gc乙個反應的時間. gc優先順序低,即使呼叫了system.gc也不能立刻執行.所以sleep 1秒.

於是有了如下分析：threadlocal裡面使用了乙個存在弱引用的map,當釋放掉threadlocal的強引用以後,map裡面的value卻沒有被**.而這塊 value永遠不會被訪問到了. 所以存在著記憶體洩露. 最好的做法是將呼叫threadlocal的remove方法. 說的也比較正確,當value不再使用的時候,呼叫remove的確是很好的做法.但記憶體洩露一說卻不正確。

在threadlocal的生命週期中,存在的引用如下圖: 實線代表強引用,虛線代表弱引用：

每個thread中都存在乙個map, map的型別是threadlocal.threadlocalmap. map中的key為乙個threadlocal例項. 這個map的確使用了弱引用,不過弱引用只是針對key. 每個key都弱引用指向threadlocal.當把threadlocal例項置為null以後,沒有任何強引用指向threadlocal例項,所以 threadlocal將會被gc**. 但是,value卻不能**,因為存在一條從current thread連線過來的強引用. 只有當前thread結束以後, current thread就不會存在棧中,強引用斷開, current thread, map, value將全部被gc**.

弱引用只存在於key上,所以key會被**. 而value還存在著強引用.只有thead退出以後,value的強引用鏈條才會斷掉：

public class threadlocaltest 
}).start();
system.gc();
timeunit.seconds.sleep(1);
system.gc();
timeunit.seconds.sleep(1);
system.gc();
timeunit.seconds.sleep(1);
}public static class mythreadlocal extends threadlocal 
}public static class my50mb }}

執行結果：

full gc my threadlocal 1 mb finalized. my 50 mb finalized.

可以看到,所有的都**了.為什麼要多次呼叫system.gc()? 這和finalize方法的策略有關係. finalize是乙個特別低優先順序的執行緒,當執行gc時,如果乙個物件需要被**,先執行它的finalize方法.這意味著,本次gc可能無法真正回收這個具有finalize方法的物件.留待下次**. 這裡多次呼叫system.gc正是為了給finalize留些時間.

從上面的例子可以看出,當執行緒退出以後,value被**了. 這是正確的.這說明記憶體並沒有洩露.棧中還存在著對value的強引用路線。然而在使用執行緒池時，執行緒一般是不會被銷毀的。

參考：

ThreadLocal注意事項

java DOM 注意事項

static注意事項

CSS注意事項

ThreadLocal注意事項

java DOM 注意事項

static注意事項

CSS注意事項

相關推薦