1 背景

某一天，技術交流群里面的某個群友突然提出了一個問題:"ThreadLocal 的 key 是弱引用，那么在 threadLocal.get() 的時候,發生 GC 之后，key 是否是 null？"屏幕前的你可以好好想想這個問題，在這里我先賣個關子，先講講 Java 中引用和 ThreadLocal 的那些事。

2 Java 中的引用

對于很多 Java 初學者來說，會把引用和對象給搞混淆。下面有一段代碼

User zhangsan = new User("zhangsan", 24);

這里先提個問題zhangsan到底是引用還是對象呢？很多人會認為zhangsan是個對象，如果你也是這樣認為的話那么再看一下下面一段代碼

User zhangsan;zhangsan = new User("zhangsan", 24);

這段代碼和開始的代碼其實執行效果是一致的，這段代碼的第一行 User zhangsan，定義了 zhangsan，那你認為 zhangsan 還是對象嗎？如果你還認為的話，那么這個對象應該是什么呢？的確，zhangsan 其實只是一個引用，對 JVM 內存劃分熟悉的同學應該熟悉下面的圖片:

其實 zhangsan 是棧中分配的一個引用，而 new User("zhangsan", 24) 是在堆中分配的一個對象。而 = 的作用是用來將引用指向堆中的對象的。就像你叫張三但張三是個名字而已并不是一個實際的人，他只是指向的你。

我們一般所說的引用其實都是代指的強引用，在 JDK1.2 之后引用不止這一種，一般來說分為四種：強引用、軟引用、弱引用、虛引用。而接下來我會一一介紹這四種引用。

2.1 強引用

上面我們說過了 Userzhangsan = newUser("zhangsan",24); 這種就是強引用，有點類似 C 的指針。對強引用他的特點有下面幾個:

• 強引用可以直接訪問目標對象。

• 只要這個對象被強引用所關聯，那么垃圾回收器都不會回收，那怕是拋出 OOM 異常。

• 容易導致內存泄漏。

2.2 軟引用

在Java中使用SoftReference幫助我們定義軟引用。其構造方法有兩個:

public SoftReference(T referent);public SoftReference(T referent, ReferenceQueue<? super T> q);

兩個構造方法相似，第二個比第一個多了一個引用隊列，在構造方法中的第一個參數就是我們的實際被指向的對象，這里用新建一個 SoftReference 來替代我們上面強引用的等號。 下面是構造軟引用的例子:

softZhangsan = new SoftReference(new User("zhangsan", 24));

2.2.1 軟引用有什么用？

如果某個對象只被軟引用所指向，那么他將會在內存要溢出的時候被回收，也就是當我們要出現 OOM 的時候，如果回收了一波內存還不夠，這才拋出 OOM，弱引用回收的時候如果設置了引用隊列，那么這個軟引用還會進入一次引用隊列，但是軟引用所指向的對象已經被回收了。這里要和下面的弱引用區分開來，弱引用是只要有垃圾回收，那么他所指向的對象就會被回收。下面是一個代碼例子:

public static void main(String[] args) {ReferenceQueue<User> referenceQueue = new ReferenceQueue();SoftReference softReference = new SoftReference(new User("zhangsan",24), referenceQueue);//手動觸發GCSystem.gc();Thread.sleep(1000);System.out.println("手動觸發GC:" + softReference.get());System.out.println("手動觸發的隊列:" + referenceQueue.poll());//通過堆內存不足觸發GCmakeHeapNotEnough();System.out.println("通過堆內存不足觸發GC:" + softReference.get());System.out.println("通過堆內存不足觸發GC:" + referenceQueue.poll());}private static void makeHeapNotEnough() {SoftReference softReference = new SoftReference(new byte[1024*1024*5]);byte[] bytes = new byte[1024*1024*5]; }

輸出:

手動觸發GC:User{name='zhangsan', age=24}

手動觸發的隊列:null

通過堆內存不足觸發GC:null

通過堆內存不足觸發GC:java.lang.ref.SoftReference@4b85612c

通過 -Xmx10m 設置我們堆內存大小為 10，方便構造堆內存不足的情況。可以看見我們輸出的情況，我們手動調用 System.gc 并沒有回收我們的軟引用所指向的對象，只有在內存不足的情況下才能觸發。

2.2.2 軟引用的應用

在 SoftReference 的 doc 中有這么一句話:

Soft references are most often used to implement memory-sensitive caches

也就是說軟引用經常用來實現內存敏感的高速緩存。怎么理解這句話呢？我們知道軟引用他只會在內存不足的時候才觸發，不會像強引用那用容易內存溢出，我們可以用其實現高速緩存，一方面內存不足的時候可以回收，一方面也不會頻繁回收。在高速本地緩存Caffeine中實現了軟引用的緩存，當需要緩存淘汰的時候，如果是只有軟引用指向那么就會被回收。不熟悉Caffeine的同學可以閱讀 《深入理解Caffeine》

2.3 弱引用

在 Java 中使用 WeakReference 來定義一個弱引用，上面我們說過他比軟引用更加弱，只要發生垃圾回收，若這個對象只被弱引用指向，那么就會被回收。這里我們就不多廢話了，直接上例子:

public static void main(String[] args) {WeakReference weakReference = new WeakReference(new User("zhangsan",24));System.gc();System.out.println("手動觸發GC:" + weakReference.get());}

輸出結果:

手動觸發GC:null

可以看見上面的例子只要垃圾回收一觸發，該對象就被回收了。

2.3.1 弱引用的作用

在 WeakReference 的注釋中寫到:

Weak references are most often used to implement canonicalizing mappings.

從中可以知道弱引用更多的是用來實現 canonicalizing mappings (規范化映射)。在 JDK 中 WeakHashMap 很好的體現了這個例子:

public static void main(String[] args) throws Exception {WeakHashMap<User, String> weakHashMap = new WeakHashMap();//強引用User zhangsan = new User("zhangsan", 24);weakHashMap.put(zhangsan, "zhangsan");System.out.println("有強引用的時候:map大小" + weakHashMap.size());//去掉強引用zhangsan = null;System.gc();Thread.sleep(1000);System.out.println("無強引用的時候:map大小"+weakHashMap.size());}

輸出結果為:

有強引用的時候:map大小1

無強引用的時候:map大小0

可以看出在 GC 之后我們在 map 中的鍵值對就被回收了，在 WeakHashMap 中其實只有 Key 是弱引用做關聯的，然后通過引用隊列再去對我們的 map 進行回收處理。

2.4 虛引用

虛引用是最弱的引用，在 Java 中使用 PhantomReference 進行定義。弱到什么地步呢？也就是你定義了虛引用根本無法通過虛引用獲取到這個對象，更別談影響這個對象的生命周期了。在虛引用中唯一的作用就是用隊列接收對象即將死亡的通知。

public static void main(String[] args) throws Exception {ReferenceQueue referenceQueue = new ReferenceQueue();PhantomReference phantomReference = new PhantomReference(new User("zhangsan", 24), referenceQueue);System.out.println("什么也不做，獲取:" + phantomReference.get());}

輸出結果:

什么也不做，獲取:null

在 PhantomReference 的注釋中寫到:

Phantom references are most often used for scheduling pre-mortem cleanup actions in a more flexible way than is possible with the Java finalization mechanism.

虛引用得最多的就是在對象死前所做的清理操作，這是一個比 Java 的 finalization 更靈活的機制。 在 DirectByteBuffer 中使用 Cleaner 回收堆外內存，Cleaner 是 PhantomReference 的子類，當 DirectByteBuffer 被回收時，為防止內存泄漏，通過這種方式進行回收，有點類似于下面的代碼:

public static void main(String[] args) throws Exception {Cleaner.create(new User("zhangsan", 24), () -> {System.out.println("我被回收了，當前線程:{}"+ Thread.currentThread().getName());});System.gc();Thread.sleep(1000);}

輸出:

我被回收了，當前線程:Reference Handler

3 ThreadLocal

ThreadLocal是一個本地線程副本變量工具類,基本在我們的代碼中隨處可見。這里就不過多的介紹他了。

3.1 ThreadLocal 和弱引用那些事兒

上面說了這么多關于引用的事，這里終于回到了主題了我們的 ThreadLocal 和弱引用有什么關系呢？

在我們的 Thread 類中有下面這個變量:

ThreadLocal.ThreadLocalMap threadLocals;

ThreadLocalMap 本質上也是個 Map,其中 Key 是我們的 ThreadLocal 這個對象，Value 就是我們在 ThreadLocal 中保存的值。也就是說我們的 ThreadLocal 保存和取對象都是通過 Thread 中的 ThreadLocalMap 來操作的，而 key 就是本身。在 ThreadLocalMap 中 Entry 有如下定義:

static class Entry extends WeakReference<ThreadLocal<?>> {/** The value associated with this ThreadLocal. */Object value;Entry(ThreadLocal<?> k, Object v) {super(k);value = v;}}

可以看見 Entry 是 WeakReference 的子類，而這個弱引用所關聯的對象正是我們的 ThreadLocal 這個對象。我們又回到上面的問題:

"Threadlocal 的 key 是弱引用，那么在 threadlocal.get() 的時候,發生 GC 之后，key 是否是 null？"

這個問題晃眼一看，弱引用嘛，還有垃圾回收那肯定是為 null，這其實是不對的，因為題目說的是在做 threadlocal.get() 操作，證明其實還是有強引用存在的。所以 key 并不為 null。如果我們的強引用不存在的話，那么 key 就會被回收，也就是會出現我們 value 沒被回收，key 被回收，導致 value 永遠存在，出現內存泄漏。這也是 ThreadLocal 經常會被很多書籍提醒到需要 remove() 的原因。

你也許會問看到很多源碼的 ThreadLocal 并沒有寫 remove 依然用得很好呢？那其實是因為很多源碼經常是作為靜態變量存在的，生命周期和 Class 是一樣的，而 remove 需要在那些方法或者對象里面使用 ThreadLocal，因為方法棧或者對象的銷毀從而強引用丟失，導致內存泄漏。

3.2 FastThreadLocal

FastThreadLocal 是 Netty 中提供的高性能本地線程副本變量工具。在 Netty 的 io.netty.util 中提供了很多牛逼的工具，后續會一一給大家介紹，這里就先說下 FastThreadLocal。

FastThreadLocal 有下面幾個特點:

• 使用數組代替 ThreadLocalMap 存儲數據，從而獲取更快的性能。(緩存行和一次定位，不會有 hash 沖突)

• 由于使用數組，不會出現 key 回收，value 沒被回收的尷尬局面，所以避免了內存泄漏。

總結

文章開頭的問題，為什么會被問出來，其實是對弱引用和 ThreadLocal 理解不深導致，很多時候只記著一個如果是弱引用，在垃圾回收時就會被回收，就會導致把這個觀念先入為主，沒有做更多的分析思考。所以大家再分析一個問題的時候還是需要更多的站在不同的場景上做更多的思考。

最后這篇文章被我收錄于 JGrowing-Java基礎篇，一個全面，優秀，由社區一起共建的Java學習路線，如果您想參與開源項目的維護，可以一起共建，github地址為:https://github.com/javagrowing/JGrowing ，點擊下方原文鏈接，麻煩給個小星星喲。

轉載聲明：本文轉載自「咖啡拿鐵」，點擊閱讀原文關注他

總結

以上是生活随笔為你收集整理的聊聊引用和 ThreadLocal 那些事儿的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。