?Thread Local深度解析,你學(xué)會了嗎?
今天,有個朋友問我說他想在并發(fā)條件下統(tǒng)計(jì)接口的耗時以及日期,并做一個記錄在最后統(tǒng)一保存,這里我就直接想到了ThreadLocal,其實(shí)我用ThreadLocal的場景還挺多的,畢竟項(xiàng)目需要,其實(shí)一直都想對ThreadLocal做一個總結(jié),擇日不如撞日就現(xiàn)在動手吧。
ThreadLocal概念
ThreadLocal也叫做本地線程變量,ThreadLocal中填充的是當(dāng)前線程的變量,該變量對其他線程是隔離的,ThreadLocal在每個線程中都創(chuàng)建了一個變量副本,所以每個線程中的ThreadLocal都是一個獨(dú)立的副本,自己可以訪問自己線程內(nèi)部的副本變量互不干擾。
ThreadLocal使用場景
ThreadLocal的使用也要看情況來定,按個人理解ThreadLocal大致會使用到以下場景:
- 需要全局獲取變量(保證這個變量在全局中的一致性)
- 需要解決線程安全的場景(例如:記錄每個請求的一些信息,保存到日志表中)
- 父子線程需要共享數(shù)據(jù)(例如:需要子線程的結(jié)果回調(diào)給父線程,如何保存它的唯一性)
說白了ThreadLocal就是做數(shù)據(jù)隔離,每條線程的ThreadLocal都是隔離的互不干擾,其實(shí)就是為了防止多線程環(huán)境下變量被其他線程篡改,只要記住這點(diǎn)在工作中什么場景下會使用到就一目了然了。
實(shí)際上Spring就是采用了Threadlocal來實(shí)現(xiàn)單個線程中的數(shù)據(jù)庫操作使用的是同一個數(shù)據(jù)庫連接,采用Threadlocal可以使業(yè)務(wù)層使用事務(wù)的時候不需要去管理connection對象,通過傳播級別就能管理多個事務(wù)配置之間的切換,掛起和恢復(fù)。
Spring框架里面就是用的ThreadLocal來實(shí)現(xiàn)這種隔離,主要是在TransactionSynchronizationManager這個類里面,代碼如下所示:
private static final Log logger = LogFactory.getLog(TransactionSynchronizationManager.class);
private static final ThreadLocal<Map<Object, Object>> resources =
new NamedThreadLocal<>("Transactional resources");
private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations =
new NamedThreadLocal<>("Transaction synchronizations");
private static final ThreadLocal<String> currentTransactionName =
new NamedThreadLocal<>("Current transaction name");
注意:在Spring5.2以后的版本Spring事務(wù)隔離從ThreadLocal換成了Mono響應(yīng)式編程來實(shí)現(xiàn)隔離。
圖片
ThreadLocal源碼分析
圖片
從源碼上看其實(shí)ThreadLocal的set方法并不復(fù)雜
- 獲取當(dāng)前線程對象Thread.currentThread();
- 獲取線程變量ThreadLocalMap map = getMap(t);
- 如果不為空則賦值map.set(this,value);
- 如果為空,初始化該線程對象的map變量,其中key為當(dāng)前的threadlocal變量createMap(t,value);
再看看ThreadLocal的get方法
圖片
圖片
- 返回當(dāng)前線程變量的副本中的值,如果該變量沒有當(dāng)前線程的值,則先調(diào)用initialValue方法的返回值
- initialValue方法中繼續(xù)獲取當(dāng)前線程變量(Key為當(dāng)前線程)而Value設(shè)置為null
- 如果當(dāng)前線程副本變量為空那么重新創(chuàng)建當(dāng)前線程的Map(Key為當(dāng)前線程,Value為null)
ThreadLocal如何做到線程隔離?
上面分析了ThreadLocal的set()和get()源碼,在通過get()方法獲取當(dāng)前線程中副本變量為null那么直接創(chuàng)建一個ThreadLocalMap:
圖片
從這里入手,看一下t.threadLocals。
圖片
注釋說得很清楚:ThreadLocal屬于當(dāng)前這個線程的。
注意:這個ThreadLocalMap是一個靜態(tài)內(nèi)部類。
圖片
ThreadLocalMap is a customized hash map suitable only for maintaining thread local values. No operations are exported outside of the ThreadLocal class. The class is package private to allow declaration of fields in class Thread. To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys. However, since reference queues are not used, stale entries are guaranteed to be removed only when the table starts running out of space.
到此為止其實(shí)ThreadLocal的數(shù)據(jù)隔離的真相就出來了,說白了每個線程Thread都維護(hù)了自己的一個threadLocals變量,當(dāng)線程創(chuàng)建ThreadLocal的時候,實(shí)際上數(shù)據(jù)是存在自己的線程Thread的threadLocals變量里面,可以看出來這個ThreadLocalMap這個類只有一份,在線程中,所以實(shí)現(xiàn)了線程之間的隔離。
ThreadLocalMap底層原理
圖片
雖然看著ThreadLocalMap很像是HashMap,實(shí)際上并沒有實(shí)現(xiàn)Map接口,而是它的內(nèi)部類Entry繼承了WeakReference這個弱引用,也就是說不存在鏈表的關(guān)系了。
接下來我們來看一下ThreadLocalMap的set()方法(這里圖片沒有截全):
圖片
ThreadLocalMap在存儲的時候每次都會給每一個ThreadLocal對象一個threadLocalHashCode,在插入過程中,根據(jù)ThreadLocal對象的hash值,定位到table中的位置i,int i = key.threadLocalHashCode & (len - 1);
接下來判斷如果當(dāng)前位置為null,就初始化一個Entry對象放在位置上。
圖片
如果當(dāng)前位置i不為空,又剛好這個Entry對象的key正好是即將設(shè)置的key,那么就覆蓋Entry中的value。
圖片
如果位置i不為null并且key不等于 entry,那么就找下一個空位置,直到位置為空為止然后存放。
在get的時候就會根據(jù)ThreadLocal對象的Hash值,定位到相應(yīng)位置,然后判斷該位置Entry對象中的key是否和get的key一致,如果不一致,就判斷下個位置。
如何共享ThreadLocal中的數(shù)據(jù)?
使用 InheritableThreadLocal可以實(shí)現(xiàn)多個線程訪問ThreadLocal的值。
問題是它們之間是如何實(shí)現(xiàn)傳遞的?
其實(shí)邏輯很簡單,繼續(xù)看Thread的源碼,看下初始化的時候Thread.init做了什么操作:
圖片
如果線程的inheritThreadLocals變量不為空的話,并且父線程的inheritThreadLocals不為空的話,就把線程的inheritThreadLocals給當(dāng)前線程的inheritThreadLocals。
圖片
關(guān)于ThreadLocal內(nèi)存泄露
ThreadLocal使用不當(dāng)也會出現(xiàn)問題:那就是內(nèi)存泄露。
繼續(xù)查看最開始存儲數(shù)據(jù)的Entry類的源碼:
圖片
其實(shí)文檔已經(jīng)說得很直白了:
Note that null keys (i.e. entry.get()* == null 如果 key threadlocal 為 null 了,這個 entry 就可以清除了。
ThreadLocal是一個弱引用,當(dāng)為null時,會被當(dāng)成垃圾回收 。
造成內(nèi)存泄露的原因在于ThreadLocal為null,也就是要被垃圾回收器回收了,但是此時我們的ThreadLocalMap(thread 的內(nèi)部屬性)生命周期和Thread的一樣,它不會回收,這時候就出現(xiàn)了一個現(xiàn)象。那就是ThreadLocalMap的key沒了,但是value還在,這就造成了內(nèi)存泄漏。
再詳細(xì)點(diǎn)來說,ThreadLocal在沒有外部強(qiáng)引用時,發(fā)生GC時會被回收,如果創(chuàng)建ThreadLocal的線程一直持續(xù)運(yùn)行,那么這個Entry對象中的value就有可能一直得不到回收,發(fā)生內(nèi)存泄露。
就比如線程池里面的線程,線程都是復(fù)用的,那么之前的線程實(shí)例處理完之后,出于復(fù)用的目的線程依然存活,所以,ThreadLocal設(shè)定的value值被持有,導(dǎo)致內(nèi)存泄露。
按照道理一個線程使用完,ThreadLocalMap是應(yīng)該要被清空的,但是現(xiàn)在線程被復(fù)用了。
解決辦法:
每次在使用完ThreadLocal的時候一定要remove。
為什么ThreadLocal要使用弱引用?
如果使用強(qiáng)引用,當(dāng)ThreadLocal 對象的引用(強(qiáng)引用)被回收了,ThreadLocalMap本身依然還持有ThreadLocal的強(qiáng)引用,如果沒有手動刪除這個key ,則ThreadLocal不會被回收,所以只要當(dāng)前線程不消亡,ThreadLocalMap引用的那些對象就不會被回收, 可以認(rèn)為這導(dǎo)致Entry內(nèi)存泄漏。
- 強(qiáng)引用:普通的引用,強(qiáng)引用指向的對象不會被回收。
- 軟引用:僅有軟引用指向的對象,只有發(fā)生gc且內(nèi)存不足,才會被回收。
- 弱引用:僅有弱引用指向的對象,只要發(fā)生gc就會被回收。