WeakReference帶來了什麼

轉載自： WeakReference帶來了什麼

很多人說到：java存在記憶體洩漏。

我不想反駁，因為我也開始慢慢說了，但我知道：記憶體洩漏和規範編碼是兩個完全不同的概念，是以我想說：請規範編碼

java的“記憶體洩漏”：

堆記憶體不夠用了，為什麼不夠用了？因為你認為已經過時的東西，沒有被系統釋放掉記憶體，為什麼沒有釋放掉記憶體？

- 因為你沒有顯示釋放（c++版本）

- 因為你還擁有着該對象的引用，而該對象沒有被認為是垃圾（java版本）

是以，你的編碼并不規範

WeakReference和記憶體洩漏有什麼樣的關系？

好像，沒關系，那麼WeakReference又是什麼？

讓我們先描述一個問題：我有一個對象a（它非常的消耗記憶體，比如一個bitmap），當你同時申請了20個對象在android中，你将會看到out of memory異常，但是，如果你不緩存圖檔，那麼使用者将會認為你的app的性能非常差：當你的應用涉及到gridview，而每一個item都是一個圖檔時一個沖突：不加載圖檔（性能低下） vs 加載圖檔（加載多了，程式會挂）

一個解決方法：

隻加載有限的圖檔，如5個圖檔，是的，這能解決問題，但是，你要為此付出的是什麼：手動編寫加載政策，以及釋放政策。

WeakReference是什麼：

先不看官方doc，讓我們舉個例子：對象a非常的消耗記憶體，我有一個WeakReference對象（wra），并且和對象a關聯：（wra & a are good friends）那麼，在虛拟機看來是什麼樣子呢：wra對象不是個垃圾，但是和wra對象相關聯的對象（對象a）被認為是垃圾，是的，垃圾就是垃圾，但是：垃圾并不會立刻被清理，也就意味着：你仍然可以使用對象a，如果它還沒被清理的情況下，如果對象a已經被清理呢：你必須重新建構對象a，再一次和wra關聯。

那樣做有什麼樣的好處：

你将可以肆無忌憚的申請任意多個“非常消耗記憶體”的對象（前提是讓他們和WeakReference關聯）使用這些對象前，先判定他們有沒有被清理：

• 如果是，重新建構該對象（可能重新建構并不繁瑣）
• 如果不是，直接使用

總結：WeakReference負責了釋放政策

與WeakReference類似的還有：SoftReference，大同小異

事實，并不是，看上去很美

我曾經做過實驗，按照WeakReference的做法，編寫程式，在android2.2上，程式運作正常，但是，同一套代碼運作在android4.0上，程式崩潰：out of memory，正是為了避免OOM異常，我采用了WeakReference。

但是，WeakReference，不靠譜。