5.1.垃圾对象的判定方法
5.1.1引用计数算法
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减一；任何时候计数器为0的对象就是不可能再被使用的
5.1.2可达性分析算法
这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链。当一个对象到GC roots没有任何引用链相连时，则证明此对象是不可用的。如下图所示，对象object5,object6,object7虽然互相有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。
5.2.垃圾收集算法
5.2.1 标记-清除算法
标记阶段：先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，它的标记过程其实就是上述的可达性分析算法中的标记过程,可以理解为它是最基础的算法
不足之处主要有两个：
a.效率不高
b.空间问题，标记清除之后会产生大量不连续的碎片，可能会导致后续程序需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作
5.2.2 复制算法
此算法有效解决效率问题，它将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动对顶指针，按顺序分配内存即可，实现简单，运行高效。
缺点就是:
a.将内存缩小为原来的一半，代价较高；
b.当对象存活率较高时就要进行较多的复制操作，效率将会变低。
5.2.3 标记-整理算法
标记-整理算法（Mark-Compact）的标记过程与”标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
5.3.与清理相关的方法
5.3.1 gc()
按执行机制划分Java有四种类型的垃圾回收器：
（1）串行垃圾回收器（Serial Garbage Collector）
（2）并行垃圾回收器（Parallel Garbage Collector）
（3）并发标记扫描垃圾回收器（CMS Garbage Collector）
（4）G1垃圾回收器（G1 Garbage Collector）
6.1.内存溢出
内存溢出：OOM（OutOfMemoryError）异常，即程序需要的内存超出了虚拟机可以分配内存的最大范围。在Java 虚拟机规范的描述中，除了程序计数器外，虚拟机内存的其他区域都可能发生OOM异常。
6.2.内存溢出区域
6.2.1 Java 堆溢出
Java 堆用于存储对象实例，只要不断地创建对象，并且保证垃圾回收机制清除这些对象，那么在对象数量达到最大堆限制就会产生内存溢出异常。
测试方案：无限循环new对象实例出来，在List中保存引用，防止GC回收，最终会产生OOM ,异常堆栈信息并提示Java heap space。
6.2.2 虚拟机栈和本地方法栈溢出
关于虚拟机栈和本地方法栈，Java虚拟机规范中定义了两种异常：
a.如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError 异常。
b.如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
StackOverflowError异常：
单线程条件下，通过不断递归调用方法，如不断累加的方法，如下所示
public class JavaVMStackSOF{ private int stackLength=1; public void stackLeak(){ stackLength++;//累加变量 stackLeak();//调用自身 } }
最终会产生StackOverflowError栈溢出异常；
OutOfMemoryError异常：
多线程条件下，无限循环地创建线程，并为每个线程无限循环的增加内存，最终会导致OutOfMemoryError异常。
6.2.3 方法区和运行时常量池溢出
运行时常量池是方法区的一部分。方法区用于存放Class的相关信息，如类名，访问修饰符，常量池，字段描述，方法描述等。
测试方法：
1.对于非常量池部分，运行时生成大量的动态类填满方法区;
2.对于常量池部分，无限循环调用String的intern()方法产生不同的String对象实例，并在List中保存其引用，以防止被GC回收，最终会产生溢出。
6.2.4 本机直接内存溢出
此类内存溢出一个明显的特征是在Heap Dump文件中不会看见明显的异常，如果发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO,可以考虑一下是不是这方面原因。
6.3 内存泄露
内存泄漏是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成内存空间的浪费称为内存泄漏。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你OOM。
Java内存泄漏的根本原因是长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏，尽管短生命周期对象已经不再需要，但是因为长生命周期持有它的引用而导致不能被回收。
6.3.1 静态集合类引起内存泄漏
像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。
6.3.2 集合里面的对象属性被修改，再调用remove()方法不生效
例如：
public static void main(String[] args){ Set<Person> set = new HashSet<Person>(); Person p1 = new Person("唐僧","pwd1",25); Person p2 = new Person("孙悟空","pwd2",26); Person p3 = new Person("猪八戒","pwd3",27); set.add(p1); set.add(p2); set.add(p3); System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:3 个元素! p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变 set.remove(p3); //此时remove不掉，造成内存泄漏 set.add(p3); //重新添加，居然添加成功 System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:4 个元素! for (Person person : set) { System.out.println(person); } }
6.3.3 监听器
在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。
6.3.4 各种连接
比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。
6.3.5 单例模式
不正确使用单例模式是引起内存泄漏的一个常见问题，单例对象在初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部的引用，那么这个对象将不能被JVM正常回收，导致内存泄漏
