一加Ace2 Pro真機(jī)揭曉 鈦空灰配色質(zhì)感拉滿
終于，在經(jīng)過(guò)了幾波預(yù)熱之后，一加Ace2 Pro的外觀真機(jī)圖在網(wǎng)上出現(xiàn)了。還是博主數(shù)碼閑聊站曝光的，這次的外觀設(shè)計(jì)還是延續(xù)了一加11的方案，只是細(xì)節(jié)上有了調(diào)整，例如新加入了鈦空灰
ThreadLocal是一個(gè)線程安全的，以線程為單位的數(shù)據(jù)傳遞工具。廣泛應(yīng)用于多層級(jí)數(shù)據(jù)傳遞。
ThreadLocal主要功能是跨層傳遞參數(shù),比如，Controller層的數(shù)據(jù)需要在業(yè)務(wù)邏輯層使用時(shí)，除了利用方法的參數(shù)傳遞之外還可以使用ThreadLocal傳遞。
有時(shí)候我們需要從上層傳遞一個(gè)參數(shù)到下層的方法，但是下層的方法新增一個(gè)參數(shù)的話，會(huì)違背開(kāi)閉原則，如果依賴此方法的上層比較多，那修改此方法必然會(huì)牽扯很多其他的代碼也要改動(dòng)（代碼中難免會(huì)遇到這種不合理的代碼）因此我們可以通過(guò)ThreadLocal來(lái)傳遞這個(gè)參數(shù)
另外，ThreadLocal在源碼中經(jīng)常被應(yīng)用，例如，Spring MVC的RequestContextHolder的實(shí)現(xiàn)就是使用了ThreadLocal，cglib動(dòng)態(tài)代理中也應(yīng)用了ThreadLocal等等。
public final class OperationInfoRecorder {private static final ThreadLocal<OperationInfoDTO> THREAD_LOCAL = new ThreadLocal<>(); private OperationInfoRecorder() { } public static OperationInfoDTO get() { return THREAD_LOCAL.get(); } public static void set(OperationInfoDTO operationInfoDTO) { THREAD_LOCAL.set(operationInfoDTO); } public static void remove() { THREAD_LOCAL.remove(); } }//使用OperationInfoRecorder.set(operationInfoDTO)OperationInfoRecorder.get()日常的代碼書(shū)寫(xiě)中需要注意兩點(diǎn)：
先來(lái)看看ThreadLocal設(shè)計(jì)的巧妙之處，通過(guò)一段源碼深入了解
public static void set(OperationInfoDTO operationInfoDTO) { THREAD_LOCAL.set(operationInfoDTO); }public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); }跟到這里發(fā)現(xiàn)獲取當(dāng)前線程，當(dāng)前線程參與進(jìn)來(lái)了，進(jìn)入createMap方法
void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue);}此處實(shí)際上就是創(chuàng)建了一個(gè)ThreadLocalMap對(duì)象，賦值給當(dāng)前線程的threadLocals屬性。
我們?nèi)サ絋hread類中看看這個(gè)屬性到底是什么
public class Thread implements Runnable {ThreadLocal.ThreadLocalMap threadLocals = null;ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;}可見(jiàn)每個(gè)線程對(duì)象中都有兩個(gè)屬性，這兩個(gè)屬性都是ThreadLocalMap類型。
看到這里不難想象，ThreadLocal對(duì)外聲稱的數(shù)據(jù)線程隔離不過(guò)是把數(shù)據(jù)保存到了當(dāng)前線程對(duì)象里面，自然是線程隔離以及線程安全了。
那么ThreadLocalMap和ThreadLocal是什么關(guān)系呢？
圖片
如圖：
ThreadLocalMap內(nèi)部有一個(gè)Entry數(shù)組，這個(gè)數(shù)組中的每個(gè)元素都是一個(gè)key-value鍵值對(duì)，value是要存儲(chǔ)的值，key是通過(guò)WeakReference包裝的ThreadLocal對(duì)象的弱引用，弱引用會(huì)在每次垃圾回收的時(shí)候被回收。
在代碼結(jié)構(gòu)上ThreadLocalMap是ThreadLocal的靜態(tài)內(nèi)部類，真正負(fù)責(zé)存儲(chǔ)數(shù)據(jù)的是ThreadLocalMap。
在應(yīng)用上，ThreadLocal為T(mén)hreadLocalMap提供了對(duì)外訪問(wèn)的api，包括set，get，remove。同時(shí)ThreadLocal對(duì)象的引用又作為T(mén)hreadLocalMap中Entry元素的key。
既然是數(shù)組，插入數(shù)據(jù)的時(shí)候是怎么解決hash沖突呢？
ThreadLocalMap采用開(kāi)放尋址法插入數(shù)據(jù)。就是如果發(fā)現(xiàn)hash沖突，就依次向后面的尋找一個(gè)空桶，直到找到為止，然后插入進(jìn)去。
那么為什么使用開(kāi)地址法？而不是像hash表一樣使用鏈表法呢？
在開(kāi)放尋址法中，所有的數(shù)據(jù)都存儲(chǔ)在一個(gè)數(shù)組中，比起鏈表法來(lái)說(shuō)，沖突的代價(jià)更高。所以，使用開(kāi)放尋址法解決沖突的散列表，裝載因子的上限不能太大。這也導(dǎo)致這種方法比鏈表法更浪費(fèi)內(nèi)存空間。但是反過(guò)看，鏈表法指針需要額外的空間，故當(dāng)結(jié)點(diǎn)規(guī)模較小時(shí)，開(kāi)放尋址法較為節(jié)省空間，而若將節(jié)省的指針空間用來(lái)擴(kuò)大散列表的規(guī)模，可使裝填因子變小，這又減少了開(kāi)放尋址法中的沖突，從而提高平均查找速度。并且使用中很少有大量ThreadLocal對(duì)象的場(chǎng)景。
1.第一次set數(shù)據(jù)
public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); } void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue); } ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) { table = new Entry[INITIAL_CAPACITY]; int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); table[i] = new Entry(firstKey, firstValue); size = 1; setThreshold(INITIAL_CAPACITY); }第一次set數(shù)據(jù)比較簡(jiǎn)單，線程中尚未初始化ThreadLocalMap，需要先初始化，初始化步驟如下：
1.非第一次set數(shù)據(jù)
private void set(ThreadLocal<?> key, Object value) { Entry[] tab = table; int len = tab.length; int i = key.threadLocalHashCode & (len-1); for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) { ThreadLocal<?> k = e.get(); if (k == key) { e.value = value; return; } if (k == null) { replaceStaleEntry(key, value, i); return; } } tab[i] = new Entry(key, value); int sz = ++size; if (!cleanSomeSlots(i, sz) && sz >= threshold) rehash(); }上面的代碼步驟如下：
private void replaceStaleEntry(ThreadLocal<?> key, Object value, int staleSlot) { Entry[] tab = table; int len = tab.length; Entry e; int slotToExpunge = staleSlot; for (int i = prevIndex(staleSlot, len); (e = tab[i]) != null; i = prevIndex(i, len)){ if (e.get() == null) slotToExpunge = i; } for (int i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) { ThreadLocal<?> k = e.get(); if (k == key) { e.value = value; tab[i] = tab[staleSlot]; tab[staleSlot] = e; if (slotToExpunge == staleSlot) slotToExpunge = i; cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); return; } if (k == null && slotToExpunge == staleSlot) slotToExpunge = i; } tab[staleSlot].value = null; tab[staleSlot] = new Entry(key, value); if (slotToExpunge != staleSlot) cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); }replaceStaleEntry方法是對(duì)set過(guò)程中遇到的失效Entry做進(jìn)一步處理，replaceStaleEntry代碼中執(zhí)行步驟如下：
1. 從當(dāng)前下標(biāo)為staleSlot的地方向左遍歷，直到找到第一個(gè)空桶停止遍歷，此時(shí)slotToExpunge=staleSlot，或者直到找到第一個(gè)非空桶且Entry對(duì)象的key為空為止，此時(shí)slotToExpunge為當(dāng)前桶下標(biāo)。此處可能說(shuō)的有點(diǎn)繞，但是相信自己看代碼就能明白。
2. 從當(dāng)前下標(biāo)為staleSlot的地方向右遍歷，此遍歷的目的是為了查看右側(cè)是否存在key相同的Entry，如果有，就更新value，并且和staleSlot下標(biāo)對(duì)應(yīng)的桶中的失效Entry交換位置，如果沒(méi)有就直接更新staleSlot下標(biāo)的桶。
這里為什么不直接更新staleSlot下標(biāo)對(duì)應(yīng)的桶呢？
因?yàn)镋ntry數(shù)組插入的時(shí)候如果遇到hash沖突(即兩個(gè)key計(jì)算出的下標(biāo)相同)，直接是依次插到后面一個(gè)空桶，如果再后來(lái)的數(shù)據(jù)插入的時(shí)候發(fā)現(xiàn)對(duì)應(yīng)下標(biāo)的桶已經(jīng)被占用，這種情況也是向后一個(gè)空桶插入。因此可以知道，不直接更新而是向后遍歷查看key是否相等，就類似于hash表插入的時(shí)候發(fā)生hash沖突后對(duì)鏈表的遍歷查找。只不過(guò)多了一個(gè)為止交換。
3. 每一次插入完成，就要執(zhí)行expungeStaleEntry方法和cleanSomeSlots方法，這個(gè)兩個(gè)方法都是失效清理方法。
expungeStaleEntry方法為探測(cè)式清理，從給定開(kāi)始的下標(biāo)開(kāi)始向右遍歷，直到第一個(gè)空桶為止
private int expungeStaleEntry(int staleSlot) { Entry[] tab = table; int len = tab.length; tab[staleSlot].value = null; tab[staleSlot] = null; size--; Entry e; int i; for (i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) { ThreadLocal<?> k = e.get(); if (k == null) { e.value = null; tab[i] = null; size--; } else { int h = k.threadLocalHashCode & (len - 1); if (h != i) { tab[i] = null; // Unlike Knuth 6.4 Algorithm R, we must scan until // null because multiple entries could have been stale. while (tab[h] != null) h = nextIndex(h, len); tab[h] = e; } } } return i; }還記得這個(gè)變量嗎slotToExpunge，這個(gè)變量的值是向左遍歷得到的第一個(gè)Entry失效的桶的下標(biāo)。
此方法做的事情就是從這個(gè)下標(biāo)開(kāi)始向右把失效的Entry全部清除，而把沒(méi)有失效的Entry重新計(jì)算下標(biāo)，重新按照開(kāi)放地址法放到數(shù)組中。直到第一個(gè)空桶停止遍歷。并且把當(dāng)前遍歷到的桶的下標(biāo)返回。
我們先來(lái)總結(jié)下這個(gè)過(guò)程的幾個(gè)關(guān)鍵點(diǎn)
那么為什么這么做呢？
首先，之所以只操作兩個(gè)空桶之間的元素，是因?yàn)閮蓚€(gè)空桶之間的元素都和當(dāng)前key計(jì)算的下標(biāo)有關(guān)系（有可能是hash沖突造成的臨近元素），操作這一部分?jǐn)?shù)據(jù)可以保證與當(dāng)前key相關(guān)的元素都能得到失效處理。
然后就是小范圍的失效操作，避免大量數(shù)據(jù)參與，可以提高性能。
最后是可以使得rehash后的數(shù)據(jù)距離正確的位置更近一些，能提高整個(gè)散列表的查詢性能。
同時(shí)這個(gè)方法會(huì)在set，get，remove，resize方法中反復(fù)使用，因此不能大規(guī)模掃描。
private boolean cleanSomeSlots(int i, int n) { boolean removed = false; Entry[] tab = table; int len = tab.length; do { i = nextIndex(i, len); Entry e = tab[i]; if (e != null && e.get() == null) { n = len; removed = true; i = expungeStaleEntry(i); } } while ( (n >>>= 1) != 0); return removed; }cleanSomeSlots方法為啟發(fā)式清理，從給定開(kāi)始的下標(biāo)開(kāi)始向右遍歷log2n個(gè)位置，對(duì)遍歷過(guò)程中失效元素調(diào)用expungeStaleEntry方法，目的也是在不影響性能的基礎(chǔ)上盡可能的多的把失效的元素清除。
public T get() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return setInitialValue(); } private Entry getEntry(ThreadLocal<?> key) { int i = key.threadLocalHashCode & (table.length - 1); Entry e = table[i]; if (e != null && e.get() == key) return e; else return getEntryAfterMiss(key, i, e); } private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) { Entry[] tab = table; int len = tab.length; while (e != null) { ThreadLocal<?> k = e.get(); if (k == key) return e; if (k == null) expungeStaleEntry(i); else i = nextIndex(i, len); e = tab[i]; } return null; }get方法要比set方法簡(jiǎn)單，邏輯步驟如下
getEntryAfterMiss方法就是從當(dāng)前坐標(biāo)開(kāi)始向后檢查key是否相等，相等的直接返回，如果失效，就調(diào)用expungeStaleEntry做失效處理，如果沒(méi)有找到就返回null。
private void remove(ThreadLocal<?> key) { Entry[] tab = table; int len = tab.length; int i = key.threadLocalHashCode & (len-1); for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) { if (e.get() == key) { e.clear(); expungeStaleEntry(i); return; } } }remove方法就更加簡(jiǎn)單了，遍歷找到key相等的元素，進(jìn)行刪除，順便在當(dāng)前坐標(biāo)位置開(kāi)始調(diào)用expungeStaleEntry進(jìn)行失效處理
private void resize() { Entry[] oldTab = table; int oldLen = oldTab.length; int newLen = oldLen * 2; Entry[] newTab = new Entry[newLen]; int count = 0; for (int j = 0; j < oldLen; ++j) { Entry e = oldTab[j]; if (e != null) { ThreadLocal<?> k = e.get(); if (k == null) { e.value = null; // Help the GC } else { int h = k.threadLocalHashCode & (newLen - 1); while (newTab[h] != null) h = nextIndex(h, newLen); newTab[h] = e; count++; } } } setThreshold(newLen); size = count; table = newTab; }擴(kuò)容機(jī)制也比較簡(jiǎn)單，在擴(kuò)容前會(huì)先調(diào)用expungeStaleEntry進(jìn)行一次失效處理，這此失效處理是在坐標(biāo)0開(kāi)始，失效處理結(jié)束后如果size >= threshold - threshold / 4，那就進(jìn)行擴(kuò)容
擴(kuò)容步驟
在ThreadLocalMap中使用WeakReference包裝后的ThreadLocal對(duì)象作為key，也就是說(shuō)這里對(duì)ThreadLocal對(duì)象為弱引用。當(dāng)ThreadLocal對(duì)象在ThreadLocalMap引用之外，再無(wú)其他引用的時(shí)候能夠被垃圾回收
static class Entry extends WeakReference<ThreadLocal<?>> { Object value; Entry(ThreadLocal<?> k, Object v) { super(k); value = v; } }垃圾回收后，Entry對(duì)象的key變?yōu)閚ull，value還被引用著，既然key為null，那么value就不可能再被應(yīng)用，但是因?yàn)関alue被Entry引用著，Entry被ThreadLocalMap引用著，ThreadLocalMap被Thread引用著，因此線程不結(jié)束，那么該回收的內(nèi)存就會(huì)一直回收不了。
很容易出問(wèn)題的情況就是我們?cè)谑褂镁€程池的時(shí)候，線程池中的線程都是重復(fù)利用的，這時(shí)候使用threadLocal存放一些數(shù)據(jù)的話，如果在線程結(jié)束的時(shí)候沒(méi)有顯示的做清除處理，就有可能會(huì)出現(xiàn)內(nèi)存泄露問(wèn)題，甚至導(dǎo)致業(yè)務(wù)邏輯出現(xiàn)問(wèn)題。所以在使用線程池的時(shí)候需要特別注意在代碼運(yùn)行完后顯式的去清空設(shè)置的數(shù)據(jù)，如果用自定義的線程池同樣也會(huì)遇到這樣的問(wèn)題。此時(shí)需要在finally代碼塊顯式清除threadLocal中的數(shù)據(jù)。
當(dāng)然對(duì)于內(nèi)存泄露問(wèn)題，ThreadLocalMap也是做了相關(guān)處理的，通過(guò)上面的源碼知道ThreadLocalMap在get和set以及remove的時(shí)候,都會(huì)相應(yīng)的做一次探測(cè)式清理操作，但是我們也說(shuō)了這種清除是小范圍的，是不能100%保證能夠清理干凈的。
我們可以通過(guò)以下兩種方式來(lái)避免這個(gè)問(wèn)題：
把ThreadLocal對(duì)象聲明為static，這樣ThreadLocal成為了類變量，生命周期不是和對(duì)象綁定，而是和類綁定，延長(zhǎng)了聲明周期，避免了被回收；
在使用完ThreadLocal變量后，手動(dòng)remove掉，防止ThreadLocalMap中Entry一直保持對(duì)value的強(qiáng)引用。導(dǎo)致value不能被回收。
threadlocal不支持繼承性：也就是說(shuō)，同一個(gè)ThreadLocal變量在父線程中被設(shè)置值后，在子線程中是獲取不到的。
但是父線程設(shè)置上下文就無(wú)法被子線程獲取嗎？當(dāng)然不是，thread類除了提供了threadLocals，還提供了inheritableThreadLocals，InheritableThreadLocal繼承了ThreadLocal，這個(gè)類中的父線程的值就可以在子線程中獲取到。此類重寫(xiě)了ThreadLocal的三個(gè)方法。
public class InheritableThreadLocal<T> extends ThreadLocal<T> { public InheritableThreadLocal() { } protected T childValue(T var1) { return var1; } ThreadLocalMap getMap(Thread var1) { return var1.inheritableThreadLocals; } void createMap(Thread var1, T var2) { var1.inheritableThreadLocals = new ThreadLocalMap(this, var2); }}此類是如何實(shí)現(xiàn)子線程獲取父線程保存的值的呢？下面代碼是thread類的源碼，在創(chuàng)建一個(gè)線程時(shí)，thread初始化的innt方法中會(huì)去判斷父線程的inheritThreadLocals中是否有值，如果有，直接賦值給子線程
if (inheritThreadLocals && parent.inheritableThreadLocals != null) this.inheritableThreadLocals = ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);InheritableThreadLocals的使用方式
private static final ThreadLocal<OperationInfoDTO> THREAD_LOCAL = new InheritableThreadL本文鏈接：http://www.www897cc.com/showinfo-26-14120-0.htmlThreadLocal：多線程環(huán)境下的神秘武器
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)