預備知識（引用）

Object o = new Object();

這個o，我們可以稱之為對象引用，而new Object()我們可以稱之為在內存中產生了一個對象實例。

當寫下?o=null時，只是表示o不再指向堆中object的對象實例，不代表這個對象實例不存在了。

• 強引用:?就是指在程序代碼之中普遍存在的，類似“Object obj=new Object（）”這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的對象實例。

• 軟引用:?是用來描述一些還有用但并非必需的對象。對于軟引用關聯(lián)著的對象，在系統(tǒng)將要發(fā)生內存溢出異常之前，將會把這些對象實例列進回收范圍之中進行第二次回收。如果這次回收還沒有足夠的內存，才會拋出內存溢出異常。在JDK 1.2之后，提供了SoftReference類來實現(xiàn)軟引用。

• 弱引用:?也是用來描述非必需對象的，但是它的強度比軟引用更弱一些，被弱引用關聯(lián)的對象實例只能生存到下一次垃圾收集發(fā)生之前。當垃圾收集器工作時，無論當前內存是否足夠，都會回收掉只被弱引用關聯(lián)的對象實例。在JDK 1.2之后，提供了WeakReference類來實現(xiàn)弱引用。

• 虛引用:?也稱為幽靈引用或者幻影引用，它是最弱的一種引用關系。一個對象實例是否有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個對象實例。為一個對象設置虛引用關聯(lián)的唯一目的就是能在這個對象實例被收集器回收時收到一個系統(tǒng)通知。在之后，提供了類來實現(xiàn)虛引用

內存泄漏的現(xiàn)象

/**
 * 類說明：ThreadLocal造成的內存泄漏演示
 */
public class ThreadLocalOOM {
    private static final int TASK_LOOP_SIZE = 500;

    final static ThreadPoolExecutor poolExecutor
            = new ThreadPoolExecutor(5, 5,
            1,
            TimeUnit.MINUTES,
            new LinkedBlockingQueue<>());

    static class LocalVariable {
        private byte[] a = new byte[1024*1024*5];/*5M大小的數(shù)組*/
    }

    final static ThreadLocal<LocalVariable> localVariable
            = new ThreadLocal<>();

    public static void main(String[] args) throws InterruptedException {
        Object o = new Object();
        /*5*5=25*/
        for (int i = 0; i < TASK_LOOP_SIZE; ++i) {
            poolExecutor.execute(new Runnable() {
                public void run() {
                    //localVariable.set(new LocalVariable());
                    new LocalVariable();
                    System.out.println("use local varaible");
                    //localVariable.remove();
                }
            });

            Thread.sleep(100);
        }
        System.out.println("pool execute over");
    }

}

首先只簡單的在每個任務中new出一個數(shù)組

?可以看到內存的實際使用控制在25M左右：因為每個任務中會不斷new出一個5M的數(shù)組，5*5=25M，這是很合理的。

當我們啟用了ThreadLocal以后

?

內存占用最高升至150M，一般情況下穩(wěn)定在90M左右，那么加入一個ThreadLocal后，內存的占用真的會這么多？

于是，我們加入一行代碼：

?再執(zhí)行，看看內存情況:

可以看見最高峰的內存占用也在25M左右，完全和我們不加ThreadLocal表現(xiàn)一樣。

這就充分說明，確實發(fā)生了內存泄漏。

分析

根據(jù)我們前面對ThreadLocal的分析，我們可以知道每個Thread 維護一個 ThreadLocalMap，這個映射表的 key 是 ThreadLocal實例本身，value 是真正需要存儲的 Object，也就是說 ThreadLocal 本身并不存儲值，它只是作為一個 key 來讓線程從 ThreadLocalMap 獲取 value。仔細觀察ThreadLocalMap，這個map是使用 ThreadLocal 的弱引用作為 Key 的，弱引用的對象在 GC 時會被回收。

因此使用了ThreadLocal后，引用鏈如圖所示

圖中的虛線表示弱引用。

? 這樣，當把threadlocal變量置為null以后，沒有任何強引用指向threadlocal實例，所以threadlocal將會被gc回收。這樣一來，ThreadLocalMap中就會出現(xiàn)key為null的Entry，就沒有辦法訪問這些key為null的Entry的value，如果當前線程再遲遲不結束的話，這些key為null的Entry的value就會一直存在一條強引用鏈：

Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value，而這塊value永遠不會被訪問到了，所以存在著內存泄露。

? 只有當前thread結束以后，current thread就不會存在棧中，強引用斷開，Current Thread、Map value將全部被GC回收。最好的做法是不在需要使用ThreadLocal變量后，都調用它的remove()方法，清除數(shù)據(jù)。

? 其實考察ThreadLocal的實現(xiàn)，我們可以看見，無論是get()、set()在某些時候，調用了expungeStaleEntry方法用來清除Entry中Key為null的Value，但是這是不及時的，也不是每次都會執(zhí)行的，所以一些情況下還是會發(fā)生內存泄露。只有remove()方法中顯式調用了expungeStaleEntry方法。

? 從表面上看內存泄漏的根源在于使用了弱引用，但是另一個問題也同樣值得思考：為什么使用弱引用而不是強引用？

下面我們分兩種情況討論：

??key 使用強引用：引用ThreadLocal的對象被回收了，但是ThreadLocalMap還持有ThreadLocal的強引用，如果沒有手動刪除，ThreadLocal的對象實例不會被回收，導致Entry內存泄漏。

??key 使用弱引用：引用的ThreadLocal的對象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使沒有手動刪除，ThreadLocal的對象實例也會被回收。value在下一次ThreadLocalMap調用set，get，remove都有機會被回收。

? 比較兩種情況，我們可以發(fā)現(xiàn)：由于ThreadLocalMap的生命周期跟Thread一樣長，如果都沒有手動刪除對應key，都會導致內存泄漏，但是使用弱引用可以多一層保障。

? 因此，ThreadLocal內存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一樣長，如果沒有手動刪除對應key就會導致內存泄漏，而不是因為弱引用。

為什么ThreadLocalMap的key要設置為弱引用？

在 ThreadLocalMap 中的set和get方法中，會對 key為null進行判斷，如果key為null會把value也置為null。
這樣就算忘記調用remove方法，對應的value在下次調用get、set、remove方法中的任意一個都會被清除，從而避免內存泄漏（相當于多了一層保障，但是如果后續(xù)一直不調用這些方法，依然存在內存泄漏的風險，所以最好是及時remove）。

總結

? JVM利用設置ThreadLocalMap的Key為弱引用，來避免內存泄露。

JVM利用調用remove、get、set方法的時候，回收弱引用。

當ThreadLocal存儲很多Key為null的Entry的時候，而不再去調用remove、get、set方法，那么將導致內存泄漏。

使用線程池+?ThreadLocal?時要小心，因為這種情況下，線程是一直在不斷的重復運行的，從而也就造成了value可能造成累積的情況。

錯誤使用ThreadLocal導致線程不安全

/**
 * 非安全的ThreadLocal 演示
 */
public class ThreadLocalUnsafe implements Runnable {

    public static ThreadLocal<Number> numberThreadLocal = new ThreadLocal<Number>();
    /**
     * 使用threadLocal的靜態(tài)變量
     */
    public static Number number = new Number(0);

    public void run() {
        //每個線程計數(shù)加一
        number.setNum(number.getNum() + 1);
        //將其存儲到ThreadLocal中
        numberThreadLocal.set(number);
        //延時2ms
        try {
            Thread.sleep(10);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        //輸出num值
        System.out.println("內存地址："+numberThreadLocal.get() + "，" + Thread.currentThread().getName() + "=" + numberThreadLocal.get().getNum());
    }


    public static void main(String[] args) {
        for (int i = 0; i < 5; i++) {
            new Thread(new ThreadLocalUnsafe()).start();
        }
    }

    /**
     * 一個私有的類 Number
     */
    private static class Number {
        public Number(int num) {
            this.num = num;
        }

        private int num;

        public int getNum() {
            return num;
        }

        public void setNum(int num) {
            this.num = num;
        }
    }
}

?輸出：

內存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-2=5
內存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-0=5
內存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-4=5
內存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-1=5
內存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-3=5

? 為什么每個線程都輸出5？難道他們沒有獨自保存自己的Number副本嗎？為什么其他線程還是能夠修改這個值？仔細考察下我們的代碼，我們發(fā)現(xiàn)我們的number對象是靜態(tài)的，所以每個ThreadLoalMap中保存的其實同一個對象的引用，這樣的話，當有其他線程對這個引用指向的對象實例做修改時，其實也同時影響了所有的線程持有的對象引用所指向的同一個對象實例。這也就是為什么上面的程序為什么會輸出一樣的結果：5個線程中保存的是同一Number對象的引用，在線程睡眠的時候，其他線程將num變量進行了修改，而修改的對象Number的實例是同一份，因此它們最終輸出的結果是相同的。

而上面的程序要正常的工作，應該去掉number的static 修飾，讓每個ThreadLoalMap中使用不同的number對象進行操作。

總結：ThreadLocal只保證線程隔離，不保證線程安全。文章來源地址http://www.zghlxwxcb.cn/news/detail-483598.html

到了這里，關于ThreadLocal引發(fā)的內存泄漏分析的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！