從一道面試題開始吧，ThreadLocal使用需要注意什么，或者有什么問題？

• 答：如果是在線程池中使用，會存在 1、內(nèi)存泄漏 2、臟數(shù)據(jù) 的問題
• 解決：try finally中調(diào)用 remove方法

慢慢從ThreadLocal的設計和源碼開始分析，

一、ThreadLocal結(jié)構(gòu)和存取數(shù)據(jù)

當創(chuàng)建了一個ThreadLocal對象時，可以將存放的Object對象、或者回調(diào)函數(shù)（延遲加載）放入setInitialValue中；當當前線程去獲取時，則會在當前線程Thread的屬性threadLocals中獲取，而該屬性的類型則為TheadLocal的靜態(tài)內(nèi)部類ThreadLocalMap，但是引用還是指向了Thread；而該threadLocals的ThreadLocalMap內(nèi)部維護了一個其內(nèi)部類ThreadLocal.ThreadLocalMap.Entry數(shù)組，而Entry由key和value組成，key即為當前的 new 的ThreadLocal對象本身，value為我們當前存儲的Object對象，并且key為WeakReference(弱引用)類型。

所以，ThreadLocal本身只定義了一些內(nèi)部類，而并不真實擁有任何數(shù)據(jù)，可以理解為全是空殼子；當獲取數(shù)據(jù)時若當前線程的ThreadLocal對象（內(nèi)存地址）不存在，則才會在該對象的setInitialValue中copy一份值到Thread的屬性threadLocals中，key為當前對象引用，value為存儲的Object值；當創(chuàng)建了多個ThreadLocal對象時，當每當前線程都調(diào)用過ThreadLocal進行get或set時，則會在當前線程的threadLocals中存儲多個值，

如下圖：

1、ThreadLocal#get

public T get() {
    Thread var1 = Thread.currentThread();
    ThreadLocal.ThreadLocalMap var2 = this.getMap(var1);
    if (var2 != null) {
        ThreadLocal.ThreadLocalMap.Entry var3 = var2.getEntry(this);
        if (var3 != null) {
            Object var4 = var3.value;
            return var4;
        }
    }
 
    return this.setInitialValue();
}

獲取當前的線程，并且使用當前線程去獲取ThreadLocal.ThreadLocalMap類型的對象，先看看getMap方法，

ThreadLocal.ThreadLocalMap getMap(Thread var1) {
    return var1.threadLocals;
}

什么都沒有做，只是將傳入的當前對象的threadLocals屬性返回，只是該引用還是指向了Thread本身。

繼續(xù)，

1、如果threadLocals對象本身不為null，則通過this，即當前ThreadLocal對象的引用為key，獲取對應Entry的值返回。

2、如果threadLocals對象本身為null，說明當前線程中沒有存放過任何ThreadLocal對象的引入的值。

則需要調(diào)setInitialValue方法，如下：

private T setInitialValue() {
    Object var1 = this.initialValue();
    Thread var2 = Thread.currentThread();
    ThreadLocal.ThreadLocalMap var3 = this.getMap(var2);
    if (var3 != null) {
        var3.set(this, var1);
    } else {
        this.createMap(var2, var1);
    }
 
    return var1;
}

調(diào)用當前ThreadLocal對象的initialValue方法，如果我們沒有重寫，則當前默認返回null，否則調(diào)用我們重寫的方法，可以理解為懶加載。

每個線程第一次都會調(diào)用該方法獲取的返回值，那么如果沒次調(diào)用都是返回同一個對象則Thread中存儲的就是同一個對象，需要我們自己注意（如果同一對象線程A改變之后線程B也改變了），并且也存在線程安全的問題。

還是獲取當前Map是否為null，則調(diào)用createMap方法。

如下：

void createMap(Thread var1, T var2) {
    var1.threadLocals = new ThreadLocal.ThreadLocalMap(this, var2);
}

2、ThreadLocal#set

理解完get的過程，set的就比較容易了，主要是引用本身比較繞。

public void set(T var1) {
    Thread var2 = Thread.currentThread();
    ThreadLocal.ThreadLocalMap var3 = this.getMap(var2);
    if (var3 != null) {
        var3.set(this, var1);
    } else {
        this.createMap(var2, var1);
    }
 
}

獲取到Thread的屬性threadLocals，如果是null則new一個，否則就往Map中放一個Entry對象。

二、梳理存在的問題和解決

當在線程池中使用的時候，其實大部分情況下我們都會在線程池中使用，比如Tomcat線程池。則key為弱引用，在Root gc不可達的情況下，則會被JVM進行回收。但是正是因為如此value值將永遠的游離，Root gc永遠指向不到該value值，則不能進行gc。當頻繁的調(diào)用，則這樣的對象越來越多，發(fā)生內(nèi)存泄漏。如果該對象的內(nèi)存還比較大，則會照成后續(xù)分配內(nèi)存時新生代不足，則可能照成溢出的情況（溢出的個人理解）。

并且，當循環(huán)使用線程的話，比如存放的是用戶信息，如果上一個用戶請求離開時未清除數(shù)據(jù)，下一個用戶進來直接獲取的話會拿到上一個用戶的數(shù)據(jù)，如果是存儲的積分等，則完全就是臟數(shù)據(jù)。

一并解決上面的兩個問題方法比較簡單，每次在調(diào)用代碼時增加 try finally中調(diào)用 ThreadLocal對象的remove方法，如下：

ThreadLocal#remove

public void remove() {
    ThreadLocal.ThreadLocalMap var1 = this.getMap(Thread.currentThread());
    if (var1 != null) {
        var1.remove(this);
    }
}

首先還是獲取當前的線程去獲取 Thread的屬性threadLocals調(diào)用其（ThreadLocalMap的）remove方法，如下：

private void remove(ThreadLocal<?> var1) {
    ThreadLocal.ThreadLocalMap.Entry[] var2 = this.table;
    int var3 = var2.length;
    int var4 = var1.threadLocalHashCode & var3 - 1;
 
    for(ThreadLocal.ThreadLocalMap.Entry var5 = var2[var4]; var5 != null; 
            var5 = var2[var4 = nextIndex(var4, var3)]) {
        if (var5.get() == var1) {
            var5.clear();
            this.expungeStaleEntry(var4);
            return;
        }
    }
}

根據(jù)當前的ThreadLocal引用，去Map中循環(huán)匹配，當匹配到之后，調(diào)用Entry的remove方法，其實是調(diào)用Refrence的clear方法。最后調(diào)用expungeStaleEntry方法將其對應的Entry從數(shù)組中消除。

再看看Reference的clear方法：

public void clear() {
    this.referent = null;
}

將該值直接置位null，則后續(xù)JVM會對該對象進行gc。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論