有些东西还是记下来比较好，记记随笔，欢迎批评建议。
最近有点懒啊，又开始拖拖拖了，要改要改～
在弄清楚为什么造成Android内存泄漏之前先要了解一下Java中垃圾是怎么回收的。大家都知道Java的内存回收和C／C++不同，Java有自动管理内存垃圾回收的机制，这就是GC。
在上一篇介绍的JVM内存结构中可以了解到JVM栈、程序计数器、本地方法栈都是线程私有的，这些部分的内存也是随着线程的创建与消亡而被分配和被回收，所以这些内存不需要管；而堆和方法区中的内存都是动态分配的，这些内存是由程序分配的，其回收则是由GC完成的，GC会监控对象的运行状态，当它不再被需要时就会被回收释放内存，那么GC怎么知道这些对象不再被需要然后去自动回收它们呢？
GC回收原理
GC对内存的监控可以看作是一个有向图，对象是有向图的顶点，引用关系考虑为图的有向边，从引用者指向被引用对象，有向图的起始顶点（GC Roots）根据有向图的具体实现有不同的定义，例如每个线程对象可以作为一个GC Roots。
在这个有向图中GC Roots可达的顶点对象是有效对象，说明对象还是有用的，GC不会对其进行回收，而GC Roots不可达的对象是不会再被引用的无效的，GC会对这些对象进行垃圾回收，释放内存。
有向图.png
JVM各代
我们知道GC回收主要回收堆内存，那么我们来看一下堆中具体的内存分配是怎样的。
首先堆被分解成三个部分或三个代：Young（年轻代）、Tenured（老年代）、Permanent（持久代）；
- Young（年轻代）又分为Eden分区和Survivor分区，存放新创建的对象和生命周期较短的对象。
- Tenured（老年代）用于存储较长生命周期的对象。
- Permanent（持久代）主要存放加载的类别还有方法对象。
垃圾回收一般步骤
- 所有的新生对象都存在于年轻代的Eden分区，初始状态下两个Survivor分区是空的。生命周期短的对象会在年轻代被回收。
- 当Eden分区满了的时候会出发一次小垃圾收集；
- Eden分区在清理时，无引用的对象会被清除，仍有引用的对象放到第一个Survivor分区（S0）；
- 下一次发生小垃圾收集时Eden分区发生同样的事：无引用的对象会被清除，仍有引用的对象放到另一个Survivor分区（S1）；此外S0中的仍幸存的对象也被移到S1，并且这部分对象年龄增加。所有幸存对象移到S1后，Eden分区和S0分区将被清理。此时Survivor分区幸存着不同的年龄的对象。
- 在下一个小垃圾收集，同样的过程反复进行。然而，此时Survivor分区的角色发生了互换，引用对象被移动到S0，幸存对象年龄增大。Eden和S1被清理。
- 在某次小垃圾收集发生后，幸存对象中某些对象年龄达到一个年龄阀值时就会被提升到老年代中（下图用的阀值是8）；
- 随着小垃圾收集的持续进行，幸存对象将被逐渐提升到老年代；
- 这样几乎涵盖了年轻一代的整个过程。最终，在老年代将会进行大垃圾收集，这种收集方式会清理-压缩老年代空间。
GC执行时间
GC是在优先级最低的线程中工作，所以应用中在忙时，GC一般不会被调用，但以下情况GC会执行：
- 当应用程序空闲时,即没有应用线程在运行时,GC会被调用。
- Java堆内存不足时,GC会被调用。
- 当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM就会强制地调用GC线程,以便回收内存用于新的分配。
- 若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要求,则 JVM将报“out of memory”的错误,Java应用将停止。
