※ 引述《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