如有openjdk源碼，則可用如下命令查找添加// help GC的時間和rev號

hg annotate -ufd src\java.base\share\classes\java\util\LinkedList.java

rev 66ef929d58f2 2009-11-06

可以參考《深入理解Java虛擬機》，樓主應該是有這本書的。試想一個問題，gc會檢測GC Roots。切記，是Roots！

GC Roots是由多個Root組成的。現代JVM使用的是準確性GC。達到能夠觸發GC停頓的Safepoint時，并不會檢查所有上下文和全局引用的Root。而是通過OopMap數據結構計算出對象偏移量和類型。在OopMap的輔助下，HotSpot可以快速地檢查GC Roots。

按照常規邏輯來說，不設置f.next = null確實沒有問題，但是樓主從另一個角度試想一下。

如果我從頭部刪除一個元素之后。又刪除了一次頭部元素呢？？

那么將形成：

f1.next = f2

f2.next = head

f2是被f1引用的，f1未被引用 (不考慮外部持有的情況下)

在調用完unlink之后，當前調用的線程或者方法并未達到能夠觸發GC停頓的Safepoint。那么剛剛刪除掉的f并沒有立刻回收。

此時創建新對象的時候：

如果內存不夠且新生代中能夠釋放足夠的空間，則新對象直接放入。

如果內存不夠存放新對象，新生代對象會被提升至老生代。騰出空間將放入新對象

問題就在這里了。綜上所述，如未設置f.next = null。在未觸發Safepoint的情況下連續刪除兩次頭部元素。f1和f2之間將存在引用關系。

如有新對象需要創建且新生代內存不足時。f2將被提升至老生代而不是立刻被回收。

補充：

不設置為null并不會導致內存泄露問題。

對GC優化極其細微，應當考慮目前的GC實現。引用原文中使用的JDK1.4，原始代碼在JDK12且內存足夠的情況下無明顯差別

專三黨，如有紕漏望各位前輩指正

總結

以上是生活随笔為你收集整理的java head head.next_Java: 链表head取出用后，置next=null为何可以加速gc？的全部內容，希望文章能夠幫你解決所遇到的問題。

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