建站
咨詢
售后
建站咨詢
新聞中心
這篇文章給大家介紹threadLocal出現(xiàn)內(nèi)存泄漏的原因是什么，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
創(chuàng)新互聯(lián)建站成立10余年來，這條路我們正越走越好，積累了技術(shù)與客戶資源，形成了良好的口碑。為客戶提供做網(wǎng)站、成都網(wǎng)站制作、網(wǎng)站策劃、網(wǎng)頁設(shè)計(jì)、域名注冊、網(wǎng)絡(luò)營銷、VI設(shè)計(jì)、網(wǎng)站改版、漏洞修補(bǔ)等服務(wù)。網(wǎng)站是否美觀、功能強(qiáng)大、用戶體驗(yàn)好、性價(jià)比高、打開快等等，這些對于網(wǎng)站建設(shè)都非常重要，創(chuàng)新互聯(lián)建站通過對建站技術(shù)性的掌握、對創(chuàng)意設(shè)計(jì)的研究為客戶提供一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進(jìn)步。
內(nèi)存泄漏的現(xiàn)象執(zhí)行 cn.enjoyedu.ch2.threadlocal 下的 ThreadLocalOOM，并將堆內(nèi)存大小設(shè) 置為-Xmx256m， 我們啟用一個線程池，大小固定為 5 個線程
場景 1：首先任務(wù)中不執(zhí)行任何有意義的代碼，當(dāng)所有的任務(wù)提交執(zhí)行完成 后，可以看見，我們這個應(yīng)用的內(nèi)存占用基本上為 25M 左右
場景 2：然后我們只簡單的在每個任務(wù)中 new 出一個數(shù)組，執(zhí)行完成后我們 可以看見，內(nèi)存占用基本和場景 1 同
場景 3：當(dāng)我們啟用了 ThreadLocal 以后：，執(zhí)行完成后我們可以看見，內(nèi)存占用變?yōu)榱?100M 左右
場景 4：于是，我們加入一行代碼，再執(zhí)行，看看內(nèi)存情況:
可以看見，內(nèi)存占用基本和場景 1 同。 這就充分說明，場景 3，當(dāng)我們啟用了 ThreadLocal 以后確實(shí)發(fā)生了內(nèi)存泄 漏。
分析 :
根據(jù)我們前面對 ThreadLocal 的分析，我們可以知道每個 Thread 維護(hù)一個 ThreadLocalMap，這個映射表的 key 是 ThreadLocal 實(shí)例本身，value 是真正需 要存儲的 Object，也就是說 ThreadLocal 本身并不存儲值，它只是作為一個 key 來讓線程從 ThreadLocalMap 獲取 value。仔細(xì)觀察 ThreadLocalMap，這個 map 是使用 ThreadLocal 的弱引用作為 Key 的，弱引用的對象在 GC 時(shí)會被回收。因此使用了 ThreadLocal 后，引用鏈如下圖：
圖中的虛線表示弱引用。
這樣，當(dāng)把 threadlocal 變量置為 null 以后，沒有任何強(qiáng)引用指向 threadlocal 實(shí)例，所以 threadlocal 將會被 gc 回收。導(dǎo)致ThreadLocalMap 中就會出現(xiàn) key 為 null 的 Entry，就沒有辦法訪問這些 key 為 null 的 Entry 的 value，如果當(dāng)前 線程再遲遲不結(jié)束的話，這些 key 為 null 的 Entry 的 value 就會一直存在一條強(qiáng) 引用鏈：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value，而這塊 value 永 遠(yuǎn)不會被訪問到了，所以存在著內(nèi)存泄露。
只有當(dāng)前 thread 結(jié)束以后，current thread 就不會存在棧中，強(qiáng)引用斷開， Current Thread、Map value 將全部被 GC 回收。最好的做法是不在需要使用 ThreadLocal 變量后，都調(diào)用它的 remove()方法，清除數(shù)據(jù)。
所以回到我們前面的實(shí)驗(yàn)場景，場景 3 中，雖然線程池里面的任務(wù)執(zhí)行完畢 了，但是線程池里面的 5 個線程會一直存在直到 JVM 退出，我們 set 了線程的 localVariable 變量后沒有調(diào)用 localVariable.remove()方法，導(dǎo)致線程池里面的 5 個 線程的 threadLocals 變量里面的 new LocalVariable()實(shí)例沒有被釋放。
其實(shí)考察 ThreadLocal 的實(shí)現(xiàn)，我們可以看見，無論是 get()、set()在某些時(shí) 候，調(diào)用了 expungeStaleEntry 方法用來清除 Entry 中 Key 為 null 的 Value，但是 這是不及時(shí)的，也不是每次都會執(zhí)行的，所以一些情況下還是會發(fā)生內(nèi)存泄露。 只有 remove()方法中顯式調(diào)用了 expungeStaleEntry 方法。
從表面上看內(nèi)存泄漏的根源在于使用了弱引用，但是另一個問題也同樣值得 思考：為什么使用弱引用而不是強(qiáng)引用？
下面我們分兩種情況討論：
key 使用強(qiáng)引用：對 ThreadLocal 對象實(shí)例的引用被置為 null 了，但是 ThreadLocalMap 還持有這個 ThreadLocal 對象實(shí)例的強(qiáng)引用，如果沒有手動刪除， ThreadLocal 的對象實(shí)例不會被回收，導(dǎo)致 Entry 內(nèi)存泄漏。
key 使用弱引用：對 ThreadLocal 對象實(shí)例的引用被被置為 null 了，由于 ThreadLocalMap 持有 ThreadLocal 的弱引用，即使沒有手動刪除，ThreadLocal 的 對象實(shí)例也會被回收。value 在下一次 ThreadLocalMap 調(diào)用 set，get，remove 都 有機(jī)會被回收。
比較兩種情況
我們可以發(fā)現(xiàn)：由于 ThreadLocalMap 的生命周期跟 Thread 一樣長，如果都沒有手動刪除對應(yīng) key，都會導(dǎo)致內(nèi)存泄漏，但是使用弱引用可 以多一層保障。
因此，ThreadLocal 內(nèi)存泄漏的根源是：由于 ThreadLocalMap 的生命周期跟 Thread 一樣長，如果沒有手動刪除對應(yīng) key 就會導(dǎo)致內(nèi)存泄漏，而不是因?yàn)槿跻?用。
總結(jié)：
JVM 利用設(shè)置 ThreadLocalMap 的 Key 為弱引用，來避免內(nèi)存泄露。
JVM 利用調(diào)用 remove、get、set 方法的時(shí)候，回收弱引用。
當(dāng) ThreadLocal 存儲很多 Key 為 null 的 Entry 的時(shí)候，而不再去調(diào)用 remove、 get、set 方法，那么將導(dǎo)致內(nèi)存泄漏。
使用線程池+ ThreadLocal 時(shí)要小心，因?yàn)檫@種情況下，線程是一直在不斷的 重復(fù)運(yùn)行的，從而也就造成了 value 可能造成累積的情況。
關(guān)于threadLocal出現(xiàn)內(nèi)存泄漏的原因是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
本文名稱：threadLocal出現(xiàn)內(nèi)存泄漏的原因是什么
文章地址：http://www.dlmjj.cn/article/ieooes.html
