转载自：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，不靠谱。
远程连接服务器教程)
