WeakReference
SoftReference
PhantomReference
他們都是為了更高效地利用 Heap。
WeakReference
如果壹個變量的 Reference 只剩下 WeakReference，那麽 GC 會毫不留情地把這個變量回收掉。也就是說，WeakReference 沒有能力能夠讓這個變量可以在內存中再飛壹會。
Android 開發者應該都了解 WeakReference 的用法，壹個比較典型的應用場景是 Handler ，為了避免 Memory Leak，我們會定義壹個內部靜態類，然後以 WeakReference 的形式引用 Activity，這樣壹來，隊列中的 Message （可能會排隊很長時間）就不會幹擾到 GC 回收 Activity。
public class MainActivity extends Activity {
private static final int MSG_ID = 0x00;
public void testSafeHandler() {
SafeHandler handler = new SafeHandler(this);
handler.sendEmptyMessage(MSG_ID);
}
public static class SafeHandler extends Handler {
private WeakReference<Activity> mActivityRef;
public SafeHandler(Activity activity) {
mActivityRef = new WeakReference<>(activity);
}
public void handleMessage(Message msg) {
switch (msg.what) {
case MSG_ID:
Activity activity = mActivityRef.get();
if (activity != null) {
activity.finish();
}
}
}
}
}
SoftReference
從 SoftReference 的官方定義 來看，只有當內存告急（即將 OOM）時，才會對只剩下 Soft Reference 的變量進行回收，因此 SoftReference 比較適合用來做 Cache：
Soft references are most often used to implement memory-sensitive caches.
但是 SoftReference 的 Android 版本 對此持不同意見：
In practice, soft references are inefficient for caching.
因為 SoftReference 無法提供足夠的信息可以讓 runtime 很輕松地決定 clear 它還是 keep 它。舉個例子，如果有 10 個 SoftReference 變量，並且他們所引用的變量都沒有了 Strong Reference，那麽 runtime 就懵逼了，因為它不知道該 clear 哪幾個或者 keep 哪幾個。更要命的是，runtime 不知道應該是 clear 掉 SoftReference 還是增大 Heap。
所以 Android 放棄了 SoftReference，推薦使用 android.util.LruCache 做 Cache 管理，至少 LruCache 可以根據變量的使用頻次來決定是否應該 clear 掉它，這樣就比單純使用 SoftReference 多了壹個決策條件 - 使用頻次。