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类似于可有可无的东西。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存，说白了就是一个没那么strong要求垃圾回收器将一个对象保留在内存中。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象*********************************************************

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

我曾经做过实验，按照WeakReference的做法，编写程序，在android2.2上，程序运行正常
但是，同一套代码运行在android4.0上，程序崩溃：out of memory
正是为了避免OOM异常，我采用了WeakReference
但是，，，，，

WeakReference，不靠谱
在2.2 vs 4.0上



***************************weakReference vs SoftReference************************

WeakReference是弱引用，其中保存的对象实例可以被GC回收掉。这个类通常用于在某处保存对象引用，而又不干扰该对象被GC回收，通常用于Debug、内存监视工具等程序中。因为这类程序一般要求即要观察到对象，又不能影响该对象正常的GC过程。

最近在JDK的Proxy类的实现代码中也发现了Weakrefrence的应用，Proxy会把动态生成的Class实例暂存于一个由Weakrefrence构成的Map中作为Cache。


SoftReference是强引用，它保存的对象实例，除非JVM即将OutOfMemory，否则不会被GC回收。这个特性使得它特别适合设计对象Cache。对于Cache，我们希望被缓存的对象最好始终常驻内存，但是如果JVM内存吃紧，为了不发生OutOfMemoryError导致系统崩溃，必要的时候也允许JVM回收Cache的内存，待后续合适的时机再把数据重新Load到Cache中。这样可以系统设计得更具弹性。