ThreadLocal使用，應用場景，源碼實現，內存泄漏

首先，ThreadLocal 不是用來解決共享對象的多線程訪問問題的，一般情況下，通過ThreadLocal.set() 到線程中的對象是該線程自己使用的對象，其他線程是不需要訪問的，也訪問不到的。各個線程中訪問的是不同的對象。 

另外，說ThreadLocal使得各線程能夠保持各自獨立的一個對象，並不是通過ThreadLocal.set()來實現的，而是通過每個線程中的new 對象 的操作來創建的對象，每個線程創建一個，不是什么對象的拷貝或副本。通過ThreadLocal.set()將這個新創建的對象的引用保存到各線程的自己的一個map中，每個線程都有這樣一個map，執行ThreadLocal.get()時，各線程從自己的map中取出放進去的對象，因此取出來的是各自自己線程中的對象，ThreadLocal實例是作為map的key來使用的。 

如果ThreadLocal.set()進去的東西本來就是多個線程共享的同一個對象，那么多個線程的ThreadLocal.get()取得的還是這個共享對象本身，還是有並發訪問問題。 

下面來看一個hibernate中典型的ThreadLocal的應用： 

    private static final ThreadLocal threadSession = new ThreadLocal();

    public static Session getSession() throws InfrastructureException {
        Session s = (Session) threadSession.get();
        try {
            if (s == null) {
                s = getSessionFactory().openSession();
                threadSession.set(s);
            }
        } catch (HibernateException ex) {
            throw new InfrastructureException(ex);
        }
        return s;
    }

可以看到在getSession()方法中，首先判斷當前線程中有沒有放進去session，如果還沒有，那么通過sessionFactory().openSession()來創建一個session，再將session set到線程中，實際是放到當前線程的ThreadLocalMap這個map中，這時，對於這個session的唯一引用就是當前線程中的那個ThreadLocalMap（下面會講到），而threadSession作為這個值的key，要取得這個session可以通過threadSession.get()來得到，里面執行的操作實際是先取得當前線程中的ThreadLocalMap，然后將threadSession作為key將對應的值取出。這個session相當於線程的私有變量，而不是public的。 

試想如果不用ThreadLocal怎么來實現呢？可能就要在action中創建session，然后把session一個個傳到service和dao中，這可夠麻煩的。或者可以自己定義一個靜態的map，將當前thread作為key，創建的session作為值，put到map中，應該也行，這也是一般人的想法，但事實上，ThreadLocal的實現剛好相反，它是在每個線程中有一個map，而將ThreadLocal實例作為key，這樣每個map中的項數很少，而且當線程銷毀時相應的東西也一起銷毀了，不知道除了這些還有什么其他的好處。 

 

總之，ThreadLocal不是用來解決對象共享訪問問題的，而主要是提供了保持對象的方法和避免參數傳遞的方便的對象訪問方式。歸納了兩點： 
1。每個線程中都有一個自己的ThreadLocalMap類對象，可以將線程自己的對象保持到其中，各管各的，線程可以正確的訪問到自己的對象。 
2。將一個共用的ThreadLocal靜態實例作為key，將不同對象的引用保存到不同線程的ThreadLocalMap中，然后在線程執行的各處通過這個靜態ThreadLocal實例的get()方法取得自己線程保存的那個對象，避免了將這個對象作為參數傳遞的麻煩。

 

當然如果要把本來線程共享的對象通過ThreadLocal.set()放到線程中也可以，可以實現避免參數傳遞的訪問方式，但是要注意get()到的是那同一個共享對象，並發訪問問題要靠其他手段來解決。但一般來說線程共享的對象通過設置為某類的靜態變量就可以實現方便的訪問了，似乎沒必要放到線程中。 

ThreadLocal的應用場合，我覺得最適合的是按線程多實例（每個線程對應一個實例）的對象的訪問，並且這個對象很多地方都要用到。 

 

當然ThreadLocal並不能替代同步機制，兩者面向的問題領域不同。同步機制是為了同步多個線程對相同資源的並發訪問，是為了多個線程之間進行通信的有效方式；而ThreadLocal是隔離多個線程的數據共享，從根本上就不在多個線程之間共享資源（變量），這樣當然不需要對多個線程進行同步了。所以，如果你需要進行多個線程之間進行通信，則使用同步機制；如果需要隔離多個線程之間的共享沖突，可以使用ThreadLocal，這將極大地簡化我們的程序，使程序更加易讀、簡潔。ThreadLocal類為各線程提供了存放局部變量的場所。 

 

JDK中ThreadLocal的實現：

並非在ThreadLocal中有一個Map,而是在每個Thread中存在這樣一個Map，具體是ThreadLocal.ThreadLocalMap。當用set時候，往當前線程里面的Map里 put 的key是當前的ThreadLocal對象。而不是把當前Thread作為Key值put到ThreadLocal中的Map里。 

public class ThreadLocal<T> {
    private final int threadLocalHashCode = nextHashCode();
    private static int nextHashCode = 0;
    private static final int HASH_INCREMENT = 0x61c88647;

    private static synchronized int nextHashCode() {
        int h = nextHashCode;
        nextHashCode = h + HASH_INCREMENT;
        return h;
    }

    public ThreadLocal() {
    }

    public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            return (T)map.get(this);

        // Maps are constructed lazily.  if the map for this thread
        // doesn't exist, create it, with this ThreadLocal and its
        // initial value as its only entry.
        T value = initialValue();
        createMap(t, value);
        return value;
    }

    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

    ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

    void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }

    .......

    static class ThreadLocalMap {
    　　........
    }
}

 

 

 

ThreadLocal內存泄漏：

每個Thread實例都具備一個ThreadLocal的map，以ThreadLocal Instance為key，以綁定的Object為Value。而這個map不是普通的map，它是在ThreadLocal中定義的，它和普通map的最大區別就是它的Entry是針對ThreadLocal弱引用的，即當外部ThreadLocal引用為空時，map就可以把ThreadLocal交給GC回收，從而得到一個null的key。 

這個threadlocal內部的map在Thread實例內部維護了ThreadLocal Instance和bind value之間的關系，這個map有threshold，當超過threshold時，map會首先檢查內部的ThreadLocal（前文說過，map是弱引用可以釋放）是否為null，如果存在null，那么釋放引用給gc，這樣保留了位置給新的線程。如果不存在slate threadlocal，那么double threshold。除此之外，還有兩個機會釋放掉已經廢棄的threadlocal占用的內存，一是當hash算法得到的table index剛好是一個null key的threadlocal時，直接用新的threadlocal替換掉已經廢棄的。另外每次在map中新建一個entry時（即沒有和用過的或未清理的entry命中時），會調用cleanSomeSlots來遍歷清理空間。此外，當Thread本身銷毀時，這個map也一定被銷毀了（map在Thread之內），這樣內部所有綁定到該線程的ThreadLocal的Object Value因為沒有引用繼續保持，所以被銷毀。 

從上可以看出Java已經充分考慮了時間和空間的權衡，但是因為置為null的threadlocal對應的Object Value無法及時回收。map只有到達threshold時或添加entry時才做檢查，不似gc是定時檢查，不過我們可以手工輪詢檢查，顯式調用map的remove方法，及時的清理廢棄的threadlocal內存。需要說明的是，只要不往不用的threadlocal中放入大量數據，問題不大，畢竟還有回收的機制。 

綜上，廢棄threadlocal占用的內存會在3中情況下清理： 
1 thread結束，那么與之相關的threadlocal value會被清理 
2 GC后，thread.threadlocals(map) threshold超過最大值時，會清理 
3 GC后，thread.threadlocals(map) 添加新的Entry時，hash算法沒有命中既有Entry時，會清理 
那么何時會“內存泄露”?當Thread長時間不結束，存在大量廢棄的ThreadLocal，而又不再添加新的ThreadLocal（或新添加的ThreadLocal恰好和一個廢棄ThreadLocal在map中命中）時。