Java中提供了四個(gè)級(jí)別的引用：強(qiáng)引用诚亚、軟引用、弱引用午乓、虛引用站宗，除強(qiáng)引用以外，其他的引用類型在java.lang.ref包下有具體的實(shí)現(xiàn)益愈，且均派生自java.lang.ref.Reference梢灭，如圖所示:

image.png

可以看到除了軟弱虛引用以外，Reference還有一個(gè)派生類Finalizer腕唧，該引用類型就是用于實(shí)現(xiàn)我們常說(shuō)的finalize函數(shù)的或辖。

一、??引用隊(duì)列ReferenceQueue??

在介紹引用類型之前枣接，先來(lái)介紹一個(gè)與所有引用類型都相關(guān)的一個(gè)東東：引用隊(duì)列java.lang.ref.ReferenceQueue颂暇。

ReferenceQueue可以和軟引用、弱引用但惶、虛引用結(jié)合使用耳鸯。關(guān)于ReferenceQueue，我們只需要知道最重要的一點(diǎn)：ReferenceQueue中存在的引用指向的對(duì)象不是被JVM回收了膀曾，就在回收的路上县爬。

所以RerferenceQueue能干啥？既然我們知道了最重要的那一點(diǎn)添谊，那么當(dāng)JVM回收掉對(duì)象之后财喳，就相當(dāng)于發(fā)出了一個(gè)通知告訴我們XX被回收了，那么此時(shí)我們就可以給被回收的對(duì)象交代后事斩狱，當(dāng)然交代后事這個(gè)動(dòng)作也可以放在finalize()中去做耳高，但是最好不要這么做！所踊！

這里簡(jiǎn)單順便提一下finalize的實(shí)現(xiàn)：每一個(gè)即將被回收并且包含finalize()函數(shù)的對(duì)象在正式回收前會(huì)被加入到叫做FinalizeThread線程的執(zhí)行隊(duì)列中泌枪，這個(gè)隊(duì)列就是我們的ReferenceQueue,其中隊(duì)列中的對(duì)象類型就是Finalizer，從上面的UML類圖可以看出秕岛，F(xiàn)inalizer繼承自FinalReference碌燕，每一個(gè)Finalizer包裝了實(shí)際要被回收的對(duì)象，然后隊(duì)列中的元素排隊(duì)開(kāi)始執(zhí)行finalize函數(shù)继薛，所以一個(gè)糟糕的finalize函數(shù)可能會(huì)使得對(duì)象長(zhǎng)時(shí)間被Finalizer引用修壕，而得不到釋放，將長(zhǎng)時(shí)間堆積在內(nèi)存中惋增，可能造成OOM叠殷，進(jìn)一步增加GC壓力

二、??強(qiáng)引用??

強(qiáng)引用就是程序中一般使用的引用類型诈皿，強(qiáng)引用的對(duì)象具有可觸及林束、不會(huì)被回收的特點(diǎn)像棘。例如：

StringBuffer str = new StringBuffer("Strong Reference")

在上述代碼中 str即StringBuffer實(shí)例的強(qiáng)引用，其中str局部變量分配在棧上壶冒，而StringBuffer實(shí)例分配在堆上（當(dāng)然也可能是棧上分配）缕题，如果此時(shí)再執(zhí)行如下代碼：

StringBuffer str2 = str;

那么此時(shí)StringBuffer對(duì)象實(shí)例就擁有兩個(gè)引用。那么怎么讓某個(gè)對(duì)象實(shí)例不再擁有強(qiáng)引用呢胖腾？那其實(shí)就是沒(méi)有任何引用指向該實(shí)例即可:

str = null;
str2 = null;

強(qiáng)引用具有如下特點(diǎn)：
1）強(qiáng)引用可以直接訪問(wèn)目標(biāo)對(duì)象
2）強(qiáng)引用所指向的對(duì)象在任何時(shí)候都不會(huì)被系統(tǒng)回收烟零，即使OOM
3）基于第二點(diǎn)，所以強(qiáng)引用可能會(huì)導(dǎo)致內(nèi)存泄漏

三咸作、??軟引用??

軟引用對(duì)應(yīng)實(shí)現(xiàn)為java.lang.ref.SoftReference锨阿，相比較強(qiáng)引用稍微弱一點(diǎn)，假如當(dāng)堆內(nèi)存空間不足時(shí)记罚，則回收軟引用對(duì)象墅诡。正應(yīng)如此，軟引用惩┲牵可以用來(lái)做緩存功能末早。軟引用還可以結(jié)合引用隊(duì)列ReferenceQueue使用，如果軟引用指向的對(duì)象實(shí)例被回收说庭，則JVM會(huì)將此軟引用加入到與之關(guān)聯(lián)的ReferenceQueue中然磷。

使用JVM參數(shù)-Xms7M -Xmx7m -XX:+PrintGC運(yùn)行如下代碼

public class SoftReferenceTest {
    public static void main(String[] args) {
        User user = new User("zhangsan");
        // 建立軟引用
        SoftReference<User> userSoftReference = new SoftReference<>(user);

        // 去除user實(shí)例的強(qiáng)引用
        user = null;

        // 手動(dòng)執(zhí)行GC
        System.gc();

        // 嘗試獲取user對(duì)象
        if (userSoftReference.get() != null){
            System.out.println(userSoftReference.get().getUsername());
        }

        // 嘗試分配4M的大對(duì)象
        byte[] bytes = new byte[1024*1024*4];

        // 再次嘗試獲取
        System.out.println("After OOM:"+userSoftReference.get());
    }
}

class User {
    private String username;

    private byte[] bytes = new byte[1024*1024*4];

    public User(String username) {
        this.username = username;
    }

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }
}

運(yùn)行后結(jié)果:

[GC (Allocation Failure)  1536K->819K(7680K), 0.0008617 secs]
[GC (Allocation Failure)  2355K->1300K(7680K), 0.0011494 secs]
[GC (System.gc())  6566K->5524K(7680K), 0.0026548 secs]
[Full GC (System.gc())  5524K->5258K(7680K), 0.0099074 secs]
zhangsan
[GC (Allocation Failure)  5307K->5322K(7680K), 0.0004518 secs]
[Full GC (Ergonomics)  5322K->5155K(7680K), 0.0117789 secs]
[GC (Allocation Failure)  5155K->5155K(7680K), 0.0004186 secs]
[Full GC (Allocation Failure)  5155K->1041K(7680K), 0.0093553 secs]
After OOM:null

在示例程序中，堆的大小為7M刊驴，并開(kāi)啟了PrintGC參數(shù)姿搜，用于發(fā)生GC時(shí)打印GC日志。接下來(lái)分為兩部分：

第一部分：在main程序中首先新建了一個(gè)User對(duì)象捆憎，在User對(duì)象內(nèi)部持有一個(gè)4M大小的字節(jié)數(shù)組痪欲，暫且就認(rèn)為這個(gè)對(duì)象實(shí)例大小為4M（當(dāng)然肯定大于4M），然后為新建的User實(shí)例建立軟引用后攻礼，去除該User對(duì)象實(shí)例的強(qiáng)引用。此時(shí)通過(guò)System.gc()手動(dòng)進(jìn)行垃圾回收的觸發(fā)之后栗柒，可見(jiàn)依然能夠獲取到user對(duì)象實(shí)例的內(nèi)容礁扮，說(shuō)明雖然發(fā)生了垃圾回收，但是其實(shí)此時(shí)內(nèi)存充足瞬沦，并不會(huì)回收軟引用太伊。
第二部分：緊接著第一部分，然后再次嘗試分配4M大小的字節(jié)數(shù)組逛钻，由于我們的堆大小只有7M僚焦，所以此時(shí)肯定無(wú)法分配，系統(tǒng)將觸發(fā)GC曙痘，觸發(fā)GC之后芳悲，可以從回收日志看到大約回收了4M的空間（即我們的軟引用對(duì)象）立肘，使得新分配的4M字節(jié)數(shù)組可以容納。并且在這之后名扛，軟引用對(duì)象獲取到的是NULL谅年。

結(jié)論：當(dāng)系統(tǒng)發(fā)生GC時(shí)，未必會(huì)回收軟引用的對(duì)象肮韧，除非內(nèi)存資源緊張不足時(shí)融蹂，軟引用對(duì)象將被回收，所以軟引用對(duì)象不會(huì)引起內(nèi)存泄漏弄企。

應(yīng)用場(chǎng)景：緩存

四超燃、??弱引用??

弱引用相比較軟引用要稍微弱一點(diǎn)。當(dāng)系統(tǒng)發(fā)生GC時(shí)拘领，不管此時(shí)系統(tǒng)資源是否充足意乓，都會(huì)對(duì)弱引用進(jìn)行回收,當(dāng)然通常情況下垃圾回收線程的優(yōu)先級(jí)比較低，并不一定會(huì)及時(shí)發(fā)現(xiàn)持有弱引用的對(duì)象院究。弱引用對(duì)應(yīng)的實(shí)現(xiàn)為java.lang.ref.WeakReference洽瞬。弱引用還可以結(jié)合引用隊(duì)列ReferenceQueue使用，如果弱引用指向的對(duì)象實(shí)例被回收业汰，則JVM會(huì)將此弱引用加入到與之關(guān)聯(lián)的ReferenceQueue中伙窃。

使用JVM參數(shù)-Xms10M -Xmx10M -XX:+PrintGC運(yùn)行如下代碼：

public class WeakReferenceTask {
    public static void main(String[] args) {
        User user = new User("zhangsan");
        // 建立弱引用
        WeakReference<User> userSoftReference = new WeakReference<>(user);

        // 去除user實(shí)例的強(qiáng)引用
        user = null;

        // 手動(dòng)執(zhí)行GC
        System.gc();
        System.out.println(userSoftReference.get());

    }
}

class User {
    private String username;

    private byte[] bytes = new byte[1024 * 1024 * 4];

    public User(String username) {
        this.username = username;
    }

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }
}

得到以下輸入：

[GC (System.gc())  5747K->4784K(9728K), 0.0008500 secs]
[Full GC (System.gc())  4784K->596K(9728K), 0.0046863 secs]
null

從輸出中可以看到，在手動(dòng)強(qiáng)制進(jìn)行GC之后样漆，有明顯大概4M空間的回收为障，且我們獲取到的user是null，說(shuō)明再本次GC中放祟，我們的弱引用對(duì)象被回收了鳍怨。

看完了軟引用和弱引用之后，可以看到這兩種引用都是比較適合做那些可有可無(wú)的緩存跪妥。當(dāng)系統(tǒng)內(nèi)存資源不足時(shí)鞋喇，這些緩存數(shù)據(jù)將被回收，以提供更多的內(nèi)存空間眉撵。當(dāng)系統(tǒng)內(nèi)存資源充足時(shí)侦香，這些緩存數(shù)據(jù)又可以存在相當(dāng)長(zhǎng)的時(shí)間。

應(yīng)用場(chǎng)景：
1） ThreadLocal解決內(nèi)存泄漏

先來(lái)看ThreadLocal源碼中哪里用到了弱引用:
ThreadLocal.ThreadLocalMap

        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }

每一個(gè)線程都會(huì)有一個(gè)ThreadLocal.ThreadLocalMap,ThreadLocalMap底層其實(shí)就是一個(gè)Entry數(shù)組纽疟，Entry的key就是ThreadLocal罐韩，value就是我們要的只能被當(dāng)前線程訪問(wèn)的對(duì)象了。注意到這個(gè)Entry繼承了WeakReference污朽，并且此弱引用表示的類型就是我們Entry的key散吵，也就是ThreadLocal對(duì)象，首先來(lái)假設(shè)一下如果不按照上面這么寫，我們可能怎么去設(shè)計(jì)Entry?

    static class Entry {
        ThreadLocal<?> key;
        Object value;
    }

我們是不是會(huì)這么設(shè)計(jì)矾睦，也能達(dá)到線程獨(dú)享的目的晦款，但是這樣會(huì)有什么問(wèn)題呢？再來(lái)理一理：
1顷锰、我們代碼中使用了ThreadLocal達(dá)到線程獨(dú)享數(shù)據(jù)

public class Test1 {
    ThreadLocal<User> threadLocal = new ThreadLocal<>();
 .....
}

2柬赐、執(zhí)行Test1的Thread持有一個(gè)ThreadLocal.ThreadLocalMap
3、ThreadLocal.ThreadLocalMap持有Entry
4官紫、Entry持有ThreadLocal和Value
5肛宋、Test1對(duì)象我們使用完了，并且也被JVM回收了束世，意味著我們創(chuàng)建的這個(gè)線程獨(dú)享數(shù)據(jù)不會(huì)再使用了

上述都是強(qiáng)引用類型酝陈，而有些線程并不是創(chuàng)建完就會(huì)銷毀，可能伴隨著我們系統(tǒng)同年生同月死毁涉，那就意味著可能有些ThreadLocal以及保存的Value我們后面都不會(huì)在使用了沉帮，然后因?yàn)閺?qiáng)引用的存在，漸漸地?fù)伪宋覀兊膬?nèi)存贫堰，引發(fā)內(nèi)存溢出穆壕。

接下來(lái)重點(diǎn)就是為啥使用弱引用了
弱引用在垃圾回收時(shí)，不管資源是否充足都會(huì)回收其屏。所以如果Entry的key是一個(gè)弱引用喇勋，那么Entry的key也就是ThreadLocal將在GC時(shí)被回收掉，那么可能有人要問(wèn)了偎行，整個(gè)Entry中key是被回收掉了川背，但是Value依然被強(qiáng)引用，依然存在啊蛤袒，照樣存在內(nèi)存泄漏跋ㄔ啤！

是的妙真，所以一般只要是遇到用到了ThreadLocal的時(shí)候缴允，一定建議或者檢查是否有地方對(duì)ThreadLocal進(jìn)行remove方法，顯示移除此Entry珍德。

那么可能又有人要問(wèn)了癌椿，既然需要我們顯示remove？那還要設(shè)計(jì)key為弱引用干嘛菱阵？

我個(gè)人覺(jué)得吧，這是一個(gè)盡量解決內(nèi)存泄漏的一個(gè)方案吧缩功，因?yàn)榭傆写中牡某绦騿T忘記remove對(duì)吧晴及，或者remove永遠(yuǎn)無(wú)法被調(diào)用到等等情況，那么這個(gè)時(shí)候使用弱引用就能自動(dòng)將這些不用的對(duì)象回收嫡锌，并且在對(duì)ThreadLocal的get虑稼、set琳钉、remove時(shí)，如果在哈希查找的時(shí)候發(fā)現(xiàn)了其key是null蛛倦，那么說(shuō)明這個(gè)Entry失效了歌懒，此時(shí)ThreadLocal就可以保證幫我們將此Entry清理。

2） WeakHashMap
其實(shí)思想和TheadLocal一樣溯壶。

3）也可以用來(lái)做緩存

五及皂、??虛引用??

虛引用是四種引用類型中最弱的一種。如果一個(gè)對(duì)象實(shí)例僅持有虛引用且改，那么和沒(méi)有引用一樣验烧，虛引用對(duì)象隨時(shí)都可能被垃圾回收器進(jìn)行回收,。虛引用對(duì)應(yīng)的實(shí)現(xiàn)為java.lang.ref.PhantomReference又跛。軟引用和弱引用的使用方式比較相似碍拆，但是虛引用相比較其他引用差別就稍微大了一點(diǎn)：

1）通過(guò)虛引用調(diào)用get方法獲取到的永遠(yuǎn)都是null,即虛應(yīng)用對(duì)象永遠(yuǎn)都是不可達(dá)的，直接看源碼：

    public T get() {
        return null;
    }

2）虛引用只有一個(gè)構(gòu)造方法慨蓝，虛引用必須和一個(gè)引用隊(duì)列ReferenceQueue結(jié)合使用

應(yīng)用場(chǎng)景：
1） 堆外內(nèi)存回收

小聲嗶嗶：除此以外不知道這個(gè)虛引用還能有哪些場(chǎng)景