如何区分垃圾
引用计数算法：
来记录一个对象被引用的次数，当引用计数器为0时，代表这个对象不再被使用。
优点：实现简单，判断效率也很高。
缺点：它很难解决对象之间相互循环引用的问题。
可达性分析算法：
在主流的商用程序语言的主流实现都是通过可达性分析来判断对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用相连时，证明此对象是不可用的。
java语言中，可作为GC Roots的对象包括下面几种：
①虚拟机栈（栈帧中的本地变量表）中引用的对象。
②方法区中静态属性引用的对象。
③方法区中常量引用的对象。
④本地方法栈中JNI（即一般说的Native方法）引用的对象。
垃圾回收从哪儿开始的呢？
从哪儿开始查找哪些对象是正在被当前系统使用的。其中栈是真正进行程序执行地方，所以要获取哪些对象正在被使用，则需要从Java栈开始。同时，一个栈是与一个线程对应的，因此，如果有多个线程的话，则必须对这些线程对应的所有的栈进行检查。
同时，除了栈外，还有系统运行时的寄存器等，也是存储程序运行数据的。这样，以栈或寄存器中的引用为起点，我们可以找到堆中的对象，又从这些对象找到对堆中其他对象的引用，这种引用逐步扩展，最终以null引用或者基本类型结束，这样就形成了一颗以Java栈中引用所对应的对象为根节点的一颗对象树，如果栈中有多个引用，则最终会形成多颗对象树。在这些对象树上的对象，都是当前系统运行所需要的对象，不能被垃圾回收。而其他剩余对象，则可以视为无法被引用到的对象，可以被当做垃圾进行回收。
因此，垃圾回收的起点是一些根对象（java栈, 静态变量, 寄存器…）。而最简单的Java栈就是Java程序执行的main函数。这种回收方式，也是上面提到的“标记-清除”的回收方式
内存泄漏实例及解决方案
什么是Java中的内存泄露
java已经有垃圾回收，为什么还会出现内存泄漏已经在上篇博文里第六点提到了，请查看
JVM调优之垃圾回收
Java内存泄漏的类型、实例及解决
1.对象游离
public Item pop(){//删除栈顶元素
Item item = a[--N];
a[N] = null;//**避免对象游离**
...
return item;
}Java的垃圾收集策略是回收所有无法被访问的对象的内存。在我们对pop()的实现中，被弹出的元素的引用仍然存在于数组中。这个元素实际上就是个孤儿了，没有谁会再访问它，但Java编译器没法知道这一点，除非该引用被覆盖。这种情况（保存一个不需要的对象的引用）成为游离。在这里，避免对象游离很简单，只需将被弹出的数组元素的值设为null即可，这将覆盖无用的引用，并使系统在使用完被弹出的元素后回收它的内存
清单 1. 展示 “对象游离” 的类
public class LeakyChecksum {
private byte[] byteArray;
public synchronized int getFileChecksum(String fileName) {
int len = getFileSize(fileName);
if (byteArray == null || byteArray.length < len)
byteArray = new byte[len];
readFileContents(fileName, byteArray);
// calculate checksum and return it
}
}这个类存在很多的问题，但是我们着重来看内存泄漏。缓存缓冲区的决定很可能是根据这样的假设得出的，即该类将在一个程序中被调用许多次，因此它应该更加有效，以重用缓冲区而不是重新分配它。但是结果是，缓冲区永远不会被释放，因为它对程序来说总是可及的（除非 LeakyChecksum 对象被垃圾收集了）。更坏的是，它可以增长，却不可以缩小，所以 LeakyChecksum 将永久保持一个与所处理的最大文件一样大小的缓冲区。退一万步说，这也会给垃圾收集器带来压力，并且要求更频繁的收集；为计算未来的校验和而保持一个大型缓冲区并不是可用内存的最有效利用。
LeakyChecksum 中问题的原因是，缓冲区对于 getFileChecksum() 操作来说逻辑上是本地的，但是它的生命周期已经被人为延长了，因为将它提升到了实例字段。因此，该类必须自己管理缓冲区的生命周期，而不是让 JVM 来管理。
2. 软引用
在Java中，虽然不需要程序员手动去管理对象的生命周期，但是如果希望某些对象具备一定的生命周期的话（比如内存不足时JVM就会自动回收某些对象从而避免OutOfMemory的错误）就需要用到软引用和弱引用了。
从Java SE2开始，就提供了四种类型的引用：强引用、软引用、弱引用和虚引用。
这四种引用的概念请参考：JVM调优之基本概念
Java中提供这四种引用类型主要有两个目的：
第一：可以让程序员通过代码的方式决定某些对象的生命周期；
第二：有利于JVM进行垃圾回收。
对于强引用，我们平时在编写代码时经常会用到。而对于其他三种类型的引用，使用得最多的就是软引用和弱引用，这2种既有相似之处又有区别。它们都是用来描述非必需对象的，但是被软引用关联的对象只有在内存不足时才会被回收，而被弱引用关联的对象在JVM进行垃圾回收时总会被回收。
在SoftReference类中，有三个方法，两个构造方法和一个get方法（WekReference类似）：
两个构造方法：
public SoftReference(T referent) {
super(referent);
this.timestamp = clock;
}
public SoftReference(T referent, ReferenceQueue<? super T> q) {
super(referent, q);
this.timestamp = clock;
}get方法用来获取与软引用关联的对象的引用，如果该对象被回收了，则返回null。
在使用软引用和弱引用的时候，我们可以显示地通过System.gc()来通知JVM进行垃圾回收，但是要注意的是，虽然发出了通知，JVM不一定会立刻执行，也就是说这句是无法确保此时JVM一定会进行垃圾回收的。
如何利用软引用和弱引用解决OOM问题？
前面讲了关于软引用和弱引用相关的基础知识，那么到底如何利用它们来优化程序性能，从而避免OOM的问题呢？
下面举个例子，假如有一个应用需要读取大量的本地图片，如果每次读取图片都从硬盘读取，则会严重影响性能，但是如果全部加载到内存当中，又有可能造成内存溢出，此时使用软引用可以解决这个问题。
设计思路是：用一个HashMap来保存图片的路径 和 相应图片对象关联的软引用之间的映射关系，在内存不足时，JVM会自动回收这些缓存图片对象所占用的空间，从而有效地避免了OOM的问题。在Android开发中对于大量图片下载会经常用到。
下面这段代码是摘自博客：
http://blog.csdn.net/arui319/article/details/8489451
首先定义一个HashMap，保存软引用对象。
private Map<String, SoftReference<Bitmap>> imageCache =
new HashMap<String, SoftReference<Bitmap>>();再来定义一个方法，保存Bitmap的软引用到HashMap。
public void addBitmapToCache(String path) {
// 强引用的Bitmap对象
Bitmap bitmap = BitmapFactory.decodeFile(path);
// 软引用的Bitmap对象
SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
// 添加该对象到Map中使其缓存
imageCache.put(path, softBitmap);
}获取的时候，可以通过SoftReference的get()方法得到Bitmap对象。
public Bitmap getBitmapByPath(String path) {
// 从缓存中取软引用的Bitmap对象
SoftReference<Bitmap> softBitmap = imageCache.get(path);
// 判断是否存在软引用
if (softBitmap == null) {
return null;
}
// 取出Bitmap对象，如果由于内存不足Bitmap被回收，将取得空
Bitmap bitmap = softBitmap.get();
return bitmap;
}使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。
需要注意的是，在垃圾回收器对这个Java对象回收前，SoftReference类所提供的get方法会返回Java对象的强引用，一旦垃圾线程回收该Java对象之后，get方法将返回null。所以在获取软引用对象的代码中，一定要判断是否为null，以免出现NullPointerException异常导致应用崩溃。
3.基于数组的集合
当数组用于实现诸如堆栈或环形缓冲区之类的数据结构时，会出现另一种形式的对象游离。清单 3 中的 LeakyStack 类展示了用数组实现的堆栈的实现。在 pop() 方法中，在顶部指针递减之后，elements 仍然会保留对将弹出堆栈的对象的引用。这意味着，该对象的引用对程序来说仍然可及（即使程序实际上不会再使用该引用），这会阻止该对象被垃圾收集，直到该位置被未来的 push() 重用。
清单 3. 基于数组的集合中的对象游离
public class LeakyStack {
private Object[] elements = new Object[MAX_ELEMENTS];
private int size = 0;
public void push(Object o) { elements[size++] = o; }
public Object pop() {
if (size == 0)
throw new EmptyStackException();
else {
Object result = elements[--size];
// elements[size+1] = null;
return result;
}
}
}修复这种情况下的对象游离的方法是，当对象从堆栈弹出之后，就消除它的引用，如清单 3 中注释掉的行所示。但是这种情况 —— 由类管理其自己的内存 —— 是一种非常少见的情况，即显式地消除不再需要的对象是一个好主意。大部分时候，认为不应该使用的强行消除引用根本不会带来性能或内存使用方面的收益，通常是导致更差的性能或者 NullPointerException。该算法的一个链接实现不会存在这个问题。在链接实现中，链接节点（以及所存储的对象的引用）的生命期将被自动与对象存储在集合中的期间绑定在一起。弱引用可用于解决这个问题 —— 维护弱引用而不是强引用的一个数组 —— 但是在实际中，LeakyStack 管理它自己的内存，因此负责确保对不再需要的对象的引用被清除。使用数组来实现堆栈或缓冲区是一种优化，可以减少分配，但是会给实现者带来更大的负担，需要仔细地管理存储在数组中的引用的生命期。
如何处理碎片
由于不同Java对象存活时间是不一定的，因此，在程序运行一段时间以后，如果不进行内存整理，就会出现零散的内存碎片。碎片最直接的问题就是会导致无法分配大块的内存空间，以及程序运行效率降低。所以，在上面提到的基本垃圾回收算法中，“复制”方式和“标记-整理”方式，都可以解决碎片的问题。
如何解决同时存在的对象创建和对象回收问题
垃圾回收线程是回收内存的，而程序运行线程则是消耗（或分配）内存的，一个回收内存，一个分配内存，从这点看，两者是矛盾的。因此，在现有的垃圾回收方式中，要进行垃圾回收前，一般都需要暂停整个应用（即：暂停内存的分配），然后进行垃圾回收，回收完成后再继续应用。这种实现方式是最直接，而且最有效的解决二者矛盾的方式。
但是这种方式有一个很明显的弊端，就是当堆空间持续增大时，垃圾回收的时间也将会相应的持续增大，对应应用暂停的时间也会相应的增大。一些对相应时间要求很高的应用，比如最大暂停时间要求是几百毫秒，那么当堆空间大于几个G时，就很有可能超过这个限制，在这种情况下，垃圾回收将会成为系统运行的一个瓶颈。为解决这种矛盾，有了并发垃圾回收算法，使用这种算法，垃圾回收线程与程序运行线程同时运行。在这种方式下，解决了暂停的问题，但是因为需要在新生成对象的同时又要回收对象，算法复杂性会大大增加，系统的处理能力也会相应降低，同时，“碎片”问题将会比较难解决。
参考文档
Java 内存管理原理、内存泄漏实例及解决方案研究
Java 如何有效地避免OOM：善于利用软引用和弱引用
Android开发优化之——使用软引用和弱引用
VM调优总结（四）-垃圾回收面临的问题