一、概述
垃圾收集(Garbage Collection，GC)和内存动态分配技术诞生于1960年MIT的Lisp语言，经过半个多世纪，目前已经相当成熟了。
在Java内存运行时区域的各个部分中，程序计数器、虚拟机栈、本地方法栈都是随线程而生随线程而灭；栈中的栈帧随着方法的进入和退出做入栈和出栈操作，每一个栈帧中分配多少内存基本上是在类结构确定下来就已知的，因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟着回收了。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是Java堆和方法区的内存回收。
二、对象存活判断
1. 引用计数算法(Reference Counting)
每个对象有一个引用计数属性，新增一个引用时计数值加1，引用释放时计数值减1，计数值为0的对象可以被回收。
这种方法的实现简单，判定效率也很高，但是无法解决对象之间相互循环引用的问题。
2. 可达性分析算法(Reachability Analysis)
以一系列的称为”GC Roots”的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。
在Java语言中，可作为GC Roots的对象包括下面几种：
- 虚拟机栈(栈帧中的本地变量表)中引用的对象。
- 方法区中类静态属性实体引用的对象。
- 方法区中常量引用的对象。
- 本地方法栈中JNI(即一般说的Native方法)引用的对象。
三、垃圾收集算法
1. 标记-清除算法
最基础的收集算法是”标记-清除”(Mark-Sweep)算法，如同它的名字一样，算法分为”标记”和”清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到的。它的主要不足有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。标记-清除算法的执行过程如图1所示。
图 1：”标记-清除”算法示意图2. 复制算法
为了解决效率问题，一种称为”复制”(Copying)的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，持续复制生存期的对象则导致效率降低。复制算法的执行过程如图2所示。
图 2：”复制”算法示意图现在的商业虚拟机都采用这种收集算法来回收新生代，研究表明，新生代中的对象98%是”朝生夕死”的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例为8：1，也就是每次新生代中可用内存空间为整个新生代容量的90%(80%+10%)，只有10%的内存会被浪费。当然98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存(这里指老年代)进行分配担保。如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。
例1：以下哪些jvm的垃圾回收方式采用的是复制算法回收?
A. 新生代串行收集器 B. 老年代串行收集器 C. 并行收集器 D. 新生代并行回收收集器 E. 老年代并行回收收集器 F. cms收集器
答案：A D
3. 标记-整理算法
复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
根据老年代的特点，有人提出了另外一种”标记-整理”(Mark-Compact)算法，标记过程仍然与”标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。标记-整理算法的执行过程如图3所示。
图 3：”标记-整理”算法示意图4. 分代收集算法
GC分代的基本假设：绝大部分对象的生命周期都非常短暂，存活时间短。
当前商业虚拟机的垃圾收集都采用”分代收集”(Generational Collection)算法，这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用”标记-清理”或者”标记-整理”算法来进行回收。
四、垃圾收集器
如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。这里讨论的收集器基于JDK 1.7 Update 14之后的HotSpot虚拟机(在这个版本中正式地提供了商用的G1收集器，之前G1仍处于试验状态)，这个虚拟机包含的所有虚拟机如图4所示。
图 4：HotSpot虚拟机的垃圾收集器图4展示了7中作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表明它是属于新生代收集器还是老年代收集器。
1. Serial收集器
Serial收集器是最基本、发展历史最悠久的收集器，它是一个单线程的收集器，它的”单线程”的意义不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。Serial/Serial Old收集器的运行过程如图5所示。
- 工作线程会因内存回收而导致停顿(Stop The World)
- 与其他单线程的收集器相比，简单而高效：对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得更高的单线程收集效率。
图 5：Serial/Serial Old收集器运行示意图2. ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数(例如：-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等)、收集算法、Stop the World、对象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。ParNew收集器的运行过程如图6所示。
图 6：Serial/Serial Old收集器运行示意图ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU环境中都不能百分之百地保证可以超越Serial收集器。当然，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
3. Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。
Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而吞吐量则可以高效地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
4. Serial Old 收集器
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。
这个收集器的主要意义在于给CLient模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK1.5以及以前的版本中与Paralle Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备方案，在并发收集发生Concurrent Mode Failure时使用。
5. Parallel Old 收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和”标记-整理”算法。这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择。由于老年代Serial Old收集器在服务端应用性能上的拖累，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件条件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合给力。
直至Parallel Old收集器出现后，”吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。Parallel Old收集器的工作过程如图7所示。
图 7：Parallel Scavenge/Parallel Old收集器运行示意图6. CMS收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
从名字（包含”Mark Sweep”）上就可以看出，CMS收集器是基于”标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：
- 初始标记(CMS initial mark)
- 并发标记(CMS concurrent mark)
- 重新标记(CMS remark)
- 并发清除(CMS concurrent sweep)
其中初始标记、重新标记这两个步骤仍然需要”Stop The World”。初始标记仅仅标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
由于在耗时最长的并发标记和并发清除过程中，收集器线程可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行。从图8可以清楚地看到CMS收集器的运作步骤中并发和需要停顿的时间。
图 8：Concurrent Mark Sweep收集器运行示意图优点：并发收集、低停顿
缺点：
- CMS收集器对CPU资源非常敏感
- CMS收集器无法处理浮动垃圾，可能出现”Concurrent Mode Failure”失败而导致另一次Full GC的产生。
- CMS收集器是一款基于”标记-清除”算法实现的收集器，收集结束时会有大量空间碎片产生。
7. G1收集器
G1(Barbage-First)收集器是当今收集器技术发展的最前沿成果之一，它是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与其他GC收集器相比，G1具备以下特点：
- 并行和并发：G1能够充分利用多CPU、多核环境下的硬件优势，使用多个CPU(CPU或CPU核心)来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
- 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
- 空间整合：与CMS的”标记-清理”算法不同，G1从整体上来看是基于”标记-整理”算法实现的收集器，从局部(两个Region之间)上来看是基于”复制”算法实现的。但无论如何，这两种算法都意味着G1在运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续空间而提前触发下一次GC。
- 可预测停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为N毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java(RTSJ)的垃圾收集器的特征了。
在G1之前的其他垃圾收集器，收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域(Region)，虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔阂了，它们都是一部分(不需要连续)Region的集合。
G1收集器的运作大致可以划分为以下几个步骤：
- 初始标记(Initial Mark)：初始标记阶段仅仅是标记一下GC Roots能直接关联到的对象，并且修改TAMS(Next Top at Mark Start)的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。
- 并发标记(Concurrent Marking)：并发标记阶段是从GC Roots开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。
- 最终标记(Final Marking)：最终标记阶段则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Rememebered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并发执行。
- 筛选回收(Live Data Counting and Evacuation)：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来指定回收计划，这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。
图 9：G1收集器运行示意图五、内存分配与回收策略
Java技术体系中所提倡的自动内存管理最终可以归结为自动化地解决两个问题：给对象分配内存以及回收分配对象的内存。
对象的内存分配，从大方向讲，就是在堆上分配，对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中雨内存相关的参数的设置。
下面是几条最普遍的内存分配规则：
1. 对象优先分配在Eden区
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机执行一次Minor GC。
2. 大对象直接进入老年代
所谓大对象是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。大对象对虚拟机的内存分配来说是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前出发垃圾收集以获取足够的连续空间来安置他们。
虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配，这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝（新生代采用复制算法收集内存）。
3. 长期存活的对象进入老年代
既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机为每个对象定义了一个年龄计数器，如果对象在Eden出生并经过第1次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1.对象在Survivor区中每熬过一次Minor GC，年龄就增加1，当它的年龄增加到一定程序(默认为15岁)，就将被晋升到老年代。对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置。
4. 动态判断对象的年龄
为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象必须达到MaxTenuringThreshold才能晋升老年代，如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
5. 空间分配担保
在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么回继续检查老年最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。
六、相关问题
问：Java堆的结构是什么样子的？什么是堆中的永久代(Perm Gen space)? 需要整理使答案更简洁
JVM的堆是运行时数据区，所有类的实例和数组都是在堆上分配内存。它在JVM启动的时候被创建。对象所占的堆内存是由自动内存管理系统也就是垃圾收集器回收。
堆内存是由存活和死亡的对象组成的。存活的对象是应用可以访问的，不会被垃圾回收。死亡的对象是应用不可访问尚且还没有被垃圾收集器回收掉的对象。一直到垃圾收集器把这些对象回收掉之前，他们会一直占据堆内存空间。
虚拟机中的堆内存共划分为三个代：年轻代（Young Generation）、年老代（Old Generation）和持久代（Permanent Generation）。其中持久代主要存放的是Java类的类信息，与垃圾收集要收集的Java对象关系不大。年轻代和年老代的划分是对垃圾收集影响比较大的。
Java的垃圾收集机制主要针对新生代和老年代的内存进行回收，不同的垃圾收集算法针对不同的区域。所以Java的垃圾收集算法使用的是分代回收。一般java的对象首先进入新生代的Eden区域，当进行GC的时候会回收新生代的区域，新生代一般采用复制收集算法，将活着的对象复制到survivor区域中，如果survivor区域装在不下，就查看老年代是否有足够的空间装下新生代中的对象，如果能装下就装下，否则老年代就执行FULL GC回收自己，老年代还是装不下，就会抛出OutOfMemory的异常。
(1) 年轻代:所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。Minor GC是针对新生代的回收。
年轻代分三个区:一个Eden区，两个Survivor区(一般而言)。
大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区(两个中的一个)，当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。同时，根据程序需要，Survivor区是可以配置为多个的（多于两个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。
(2) 年老代:在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。Major GC/Full GC是针对年老代的回收。
(3) 持久代:用于存放静态文件，如类、方法、final常量、static变量等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=
例1：JVM中垃圾回收分为scanvenge gc和full GC，其中full GC触发的条件可能有哪些？
答案：老年代满、持久代满、System.gc()
问：Java中垃圾回收(GC)有什么目的？什么时候进行垃圾回收？
GC是垃圾收集的意思(Gabage Collection)，内存处理是编程人员容易出现问题的地方，忘记或者错误地内存回收会导致程序或系统的不稳定甚至崩溃，Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的。Java语言没有提供显示地释放已分配内存的操作方法。
垃圾回收器通常是作为一个单独的低级别的线程运行，在不可预知的情况下对内存堆中已经死亡的或者长时间没有使用的对象进行清除和回收，程序员不能实时的调用垃圾回收器对某个对象或所有对象进行垃圾回收。
垃圾回收的目的是识别并回收堆内存中不再使用的对象所占的内存，释放资源。而栈区的内存是随着线程结束而释放的。
对于GC来说，当程序员创建对象时，GC就开始监控这个对象的地址、大小以及使用情况。通常，GC采用有向图的方式记录和管理堆(heap)中的所有对象。通过这种方式确定哪些对象是”可达的”，哪些对象是”不可达的”。当GC确定一些对象为”不可达”时，GC就有责任回收这些内存空间。
触发主GC(Garbage Collector，垃圾回收)的条件：
(1) 当应用程序空闲时，即没有应用线程在运行时，GC会被调用。
(2) Java堆内存不足时，GC会被调用。
问：System.gc()和Runtime.gc()会做什么事情？
Java提供了垃圾回收机制来帮助我们不定时的回收堆中不再使用的对象。当JVM启动时，除了启动我们的主线程外，还会启动垃圾回收线程，它运行优先非常低，会在JVM空闲时，自动回收我们不再使用的对象，释放内存空间。
程序员不能强制执行垃圾回收，可以用这两个方法用来提示JVM要进行垃圾回收。但是，立即开始还是延迟进行垃圾回收是取决于JVM，即垃圾回收的具体时间和顺序是无法预知的。
问：如果对象的引用被置为null，垃圾收集器是否会立即释放对象占用的内存？
不会立即释放对象占用的内存，如果对象的引用被置为null，只是断开了当前线程栈帧中对该对象的引用关系，在下一个垃圾回收周期中，这个对象将是可被回收的。
问：串行(serial)收集器和吞吐量(throughput)收集器的区别是什么？
吞吐量收集器使用并行版本的新生代垃圾收集器，它适合于吞吐量要求较高的场合，用于中等规模和大规模数据的应用程序。
串行收集器整个扫描和复制过程均采用单线程的方式，相对于吞吐量GC来说简单；适合于单CPU、客户端级别。串行对大多数的小应用(在现代处理器上需要大概100M左右的内存)就足够了。
问：在Java中，对象什么时候可以被垃圾回收？
当对象对当前使用这个对象的应用程序变得不可触及的时候，这个对象就可以被回收了。
问：JVM的永久代中会发生垃圾回收么？(没看懂)
垃圾回收不会发生在永久代，如果永久代满了或者是超过了临界值，会触发完全垃圾回收(Full GC)。如果你仔细查看垃圾收集器的输出信息，就会发现永久代也是被回收的。这就是为什么正确的永久代大小对避免Full GC是非常重要的原因。
请参考下Java8：从永久代到元数据区(注：Java8中已经移除了永久代，新加了一个叫做元数据区的native内存区)
问：引用的分类
来源1：Java 如何有效地避免OOM：善于利用软引用和弱引用
JDK 1.2以前的版本中，若一个对象不被任何变量引用，那么程序就无法再使用这个对象。也就是说，只有对象处于可触及（reachable）状态，程序才能使用它。从JDK 1.2版本开始，把对象的引用分为4种级别，从而使程序能更加灵活地控制对象的生命周期。这4种级别由高到低依次为：强引用、软引用、弱引用和虚引用。
(1) 强引用(StrongReference)
强引用是使用最普遍的引用。如果一个对象具有强引用，那么垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。
public class Main {
public static void main(String[] args) {
new Main().fun1();
}
public void fun1() {
Object object = new Object();
Object[] objArr = new Object[1000];
}
}
当运行至Object[] objArr = new Object[1000];这句时，如果内存不足，JVM会抛出OOM错误也不会回收object指向的对象。不过要注意的是，当fun1运行完之后，object和objArr都已经不存在了，所以它们指向的对象都会被JVM回收。
如果想中断强引用和某个对象之间的关联，可以显示地将引用赋值为null，这样JVM就可以在合适的时间回收该对象了。
(2) 软引用(SoftReference)
软引用是用来描述一些有用但并不是必需的对象，在Java中用java.lang.ref.SoftReference类来表示。对于软引用关联着的对象，当内存空间足够时，垃圾回收器不会回收它；而只有在内存不足的时候JVM才会回收该对象。只要垃圾回收器没有回收它，该对象就可以被程序使用。因此，这一点可以很好地用来解决OOM的问题，并且这个特性很适合用来实现内存敏感的缓存：比如网页缓存、图片缓存等。
软引用可以和一个引用队列(ReferenceQueue)联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。
import java.lang.ref.SoftReference;
public class Main {
public static void main(String[] args) {
SoftReference<String> sr = new SoftReference<String>(new String("hello"));//当某个对象需要设置为软引用时，只需要给该对象放到软引用对象中即可
System.out.println(sr.get());
}
}
(3) 弱引用(WeakReference)
弱引用也是用来描述非必需对象的，当JVM进行垃圾回收时，无论内存是否充足，都会回收被弱引用关联的对象。在java中，用java.lang.ref.WeakReference类来表示。弱引用与软引用的区别在于：弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列(ReferenceQueue)联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。
import java.lang.ref.WeakReference;
public class Main {
public static void main(String[] args) {
WeakReference<String> sr = new WeakReference<String>(new String("hello"));
System.out.println(sr.get());
System.gc();//通知JVM的gc进行垃圾回收
System.out.println(sr.get());
}
}
输出：
hello
null
这说明只要JVM进行垃圾回收，被弱引用关联的对象必定会被回收掉。
不过要注意的是，这里所说的被弱引用关联的对象是指只有弱引用与之关联，如果存在强引用同时与之关联，则进行垃圾回收时也不会回收该对象（软引用也是如此）。
(4) 虚引用(PhantomReference)
“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。在java中用java.lang.ref.PhantomReference类表示。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列(ReferenceQueue)联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。
程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。
import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;
public class Main {
public static void main(String[] args) {
ReferenceQueue<String> queue = new ReferenceQueue<String>();
PhantomReference<String> pr = new PhantomReference<String>(new String("hello"), queue);
System.out.println(pr.get());
}
}
输出：
null
问：如何利用软引用和弱引用解决OOM问题
在应用的开发中，为了防止内存溢出，在处理一些占用内存大而且声明周期较长的对象时候，可以尽量应用软引用和弱引用技术。
假设我们的应用会用到大量的默认图片，比如应用中有默认的头像，默认游戏图标等等，这些图片很多地方会用到。如果每次都去读取图片，由于读取文件需要硬件操作，速度较慢，会导致性能较低。所以我们考虑将图片缓存起来，需要的时候直接从内存中读取。但是，由于图片占用内存空间比较大，缓存很多图片需要很多的内存，就可能比较容易发生OutOfMemory异常。这时，我们可以考虑使用软引用技术来避免这个问题发生。
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);
}
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异常导致应用崩溃。
问：可能发生OOM和SOF的情况及解决方法
(1) OOM
OOM：OutOfMemoryError，即内存溢出，是指程序在申请内存时，没有足够的空间供其使用，出现了Out Of Memory，也就是要求分配的内存超出了系统上限，系统不能满足其需求，于是产生溢出。
内存溢出分为上溢和下溢，比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。
有时候内存泄露会导致内存溢出，所谓内存泄露（memory leak），是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光，举个例子，就是说系统的篮子（内存）是有限的，而你申请了一个篮子，拿到之后没有归还（忘记还了或是丢了），于是造成一次内存泄漏。在你需要用篮子的时候，又去申请，如此反复，最终系统的篮子无法满足你的需求，最终会由内存泄漏造成内存溢出。
遇到的OOM：
（1）Java Heap 溢出
Java堆用于存储对象实例，我们只要不断的创建对象，而又没有及时回收这些对象（即内存泄漏），就会在对象数量达到最大堆容量限制后产生内存溢出异常。
（2）方法区溢出
方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。
异常信息：java.lang.OutOfMemoryError:PermGen space
方法区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，判定条件是很苛刻的。在经常动态生成大量Class的应用中，要特别注意这点。
(2) SOF
SOF：StackOverflow（堆栈溢出）
当应用程序递归太深而发生堆栈溢出时，抛出该错误。因为栈一般默认为1-2m，一旦出现死循环或者是大量的递归调用，在不断的压栈过程中，造成栈容量超过1m而导致溢出。
栈溢出的原因：
（1）递归调用
（2）大量循环或死循环
（3）全局变量是否过多
（4）数组、List、Map数据过大
OOM在Android开发中出现比较多，例如：加载的图片太多或图片过大、分配特大的数组、内存相应资源过多没有来不及释放等。
解决方法：
（1）在内存引用上做处理
软引用是主要用于内存敏感的高速缓存。在jvm报告内存不足之前会清除所有的软引用，这样以来gc就有可能收集软可及的对象，可能解决内存吃紧问题，避免内存溢出。什么时候会被收集取决于gc的算法和gc运行时可用内存的大小。
（2）对图片做边界压缩，配合软引用使用
（3）显示的调用GC来回收内存，如：
if(bitmapObject.isRecycled()==false) //如果没有回收
bitmapObject.recycle();
（4）优化Dalvik虚拟机的堆内存分配
》增强程序堆内存的处理效率
//在程序onCreate时就可以调用 即可
privatefinalstaticfloat TARGET_HEAP_UTILIZATION = 0.75f;
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);
》设置堆内存的大小
privatefinalstaticintCWJ_HEAP_SIZE = 6* 1024* 1024;
//设置最小heap内存为6MB大小
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);
（5）用LruCache 和 AsyncTask<>解决
从cache中去取Bitmap，如果取到Bitmap，就直接把这个Bitmap设置到ImageView上面。
如果缓存中不存在，那么启动一个task去加载（可能从文件来，也可能从网络）。