※ 引述《s3748679 (冷羽翼塵)》之銘言： ... : 而現在重點來了~ : 既定事實: (根據上幾篇看後的推測) : 如果現在GC抓_Instance1，是可以回收的! : 另一方面，現在GC抓_Instance2，是不可以回收的(因為被_Instance1參照)! : 理論上 LinkedList是存取不到 _Instance1和_Instance2。 : 以及如果GC回收_Instance1，那麼_Instance2也就變得可以回收， : 但若倒過來(先回收_Instance2再回收_Instance1)則不行。 : 問題: : 1. 在remove_x二個_Instance後，GC是否還能夠把這二個_Instance回收掉。 如你上面說的， 必須剛好 GC 先回收了 _Instance1， 才會有機會再回收 _Instance2。 : 2. 如果GC能夠回收掉，那麼寫null的意義為何? 不會是能讓GC更快回收吧? 這麼講也沒錯， 因為前面說到必須先回收 _Instance1 才能再回收 _Instance2， 但如果標上 null 後， _Instance1 和 _Instance2 就能同時回收， 這在某個程度上來講是讓回收變快了。 試著再想想 remove 了更多連續的 instances 的情況， 或是原文中 clear() 方法把所有 instances 清掉的情況。 : 3. 如果GC不能夠回收掉，那麼寫這null就很必要的了? (好灰暗啊...) 以這個例子來講， 我個人認為是必要的， 因為這樣才能讓 GC 儘早知道哪些記憶體是沒用到、可回收的， 而且要記得本例是標準程式庫中的程式碼， 它有義務儘量提高本身的效率， 不讓使用它的程式受到拖累。 關於何時該用 null 的建議， 可進一步參看 Effective Java 中的 Item 5 那一章節。 : PS: 仍舊老話那句，對於半路出家的我，希望各位能夠指點迷津~~~ =ˇ= : ...用記事本編輯好久 orz --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.175.148.211