在Java程序中对象的创建是非常频繁的，而内存的大小又是有限的，为了内存的重复利用，就需要对内存中的对象进行垃圾收集。其实，这也是Java和C++的一个区别，在Java中可以进行自动的垃圾收集，而C和C++中需要程序员手动回收不再使用的对象。
Java中的垃圾收集是虚拟机要考虑的问题。那么以虚拟机的角度考虑，如果要收集虚拟机内存中的垃圾，需要考虑哪些问题呢？
- Java虚拟机中的内存分为程序计数器、虚拟机栈、本地方法栈、Java堆和方法区等几部分，在哪些部分回收内存呢？
- 确定了要回收的内存，内存中必然存在着很多内容，如何判定这些内容就是不需要的垃圾了呢？
- 程序不断运行，垃圾收集不可能也随着程序一直运行，那什么时候进行垃圾收集操作呢？
- 最重要的问题是，怎么回收？
回收区域：
在前面几篇中可以知道，Java内存中的程序计数器、虚拟机栈和本地方法栈是线程私有的，线程结束也就没了。其中程序计数器负责指示下一条指令，栈中的栈帧随着方法的进入和退出不停的入栈出栈。每一个栈帧的大小在编译时就基本已经确定。所以这几个区域就不需要考虑内存回收，因为方法结束或线程停止，内存就回收了。
和上述三个区域不同的是，Java堆和方法区是线程共享的。在Java堆中存放着所有线程在运行时创建的对象，在方法区中存放着关于类的元数据信息。我们在程序运行时才能确定需要加载哪些类的元数据信息到方法区，创建哪些对象到堆中，也就是说，这部分的内存分配和回收都是动态的。也因为这样，这两个部分是垃圾收集器所关注的地方。
首先要搞清一个最基本的问题：如果确定某个对象是“垃圾”？既然垃圾收集器的任务是回收垃圾对象所占的空间供新的对象使用，那么垃圾收集器如何确定某个对象是“垃圾”？—即通过什么方法判断一个对象可以被回收了。在java中是通过引用来和对象进行关联的，也就是说如果要操作对象，必须通过引用来进行。那么很显然一个简单的办法就是通过引用计数来判断一个对象是否可以被回收。不失一般性，如果一个对象没有任何引用与之关联，则说明该对象基本不太可能在其他地方被使用到，那么这个对象就成为可被回收的对象了。这种方式成为引用计数法。
这种方式的特点是实现简单，而且效率较高，但是它无法解决循环引用的问题，因此在Java中并没有采用这种方式（Python采用的是引用计数法）。看下面这段代码：
public static void main(String[] args) { MyObject object1 = new MyObject(); MyObject object2 = new MyObject(); object1.object = object2; object2.object = object1; object1 = null; object2 = null; } } class MyObject{ public Object object = null; }最后面两句将object1和object2赋值为null，也就是说object1和object2指向的对象已经不可能再被访问，但是由于它们互相引用对方，导致它们的引用计数都不为0，那么垃圾收集器就永远不会回收它们。
为了解决这个问题，在Java中采取了 可达性分析法。
该方法的基本思想是通过一系列的“GC Roots”对象作为起点进行搜索，如果在“GC Roots”和一个对象之间没有可达路径，则称该对象是不可达的，不过要注意的是被判定为不可达的对象不一定就会成为可回收对象。被判定为不可达的对象要成为可回收对象必须至少经历两次标记过程，如果在这两次标记过程中仍然没有逃脱成为可回收对象的可能性，则基本上就真的成为可回收对象了。
在Java中，下面几种对象可以作为GC Roots：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象；
- 方法区中类静态属性引用的对象；
- 方法区中常量引用的对象；
- 本地方法栈中JNI（即Native方法）引用的对象；
即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，要真正认为一个对象是垃圾要收集，至少要经过两次标记过程：如果对象在进行可达性分析后发现不可达，那么就将它进行第一标记并进行一次筛选，筛选的条件是这个对象是否有必要执行finalize()方法。当对象没有覆盖finalize方法，或finalize方法已经被虚拟机执行过了，虚拟机任何没有必要执行finalize方法。
如果这个对象被判定为有必要执行finalize方法，那么这个对象会放置在一个叫做F-Queue的队列中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行。不过虚拟机只是会触发这个方法，但不承诺会等待执行完毕，这是因为，如果一个对象的finalize方法执行缓慢，或发生了死循环，就会导致F-Queue对象中的其他对象处于等待，甚至整个垃圾收集系统崩溃。稍后GC会在F-Queue中的对象进行第二次小规模的标记，如果这时标记为可达，就可以不被收集；如果仍然不可达，那么就被标记为垃圾了。具体的流程图如下：
下面的代码演示了上面所说的内容。
public class FinalizeEscapeGC { public static FinalizeEscapeGC SAVE_HOOK=null; public void isAlive(){ System.out.println("yes,i am still alive."); } protected void finalize()throws Throwable{ super.finalize(); System.out.println("finalize method executed!"); FinalizeEscapeGC.SAVE_HOOK=this; } public static void main(String[] args) throws InterruptedException { SAVE_HOOK=new FinalizeEscapeGC(); SAVE_HOOK=null; System.gc(); Thread.sleep(500); if(SAVE_HOOK!=null){ SAVE_HOOK.isAlive(); }else{ System.out.println("no,i am dead."); } SAVE_HOOK=null; System.gc(); Thread.sleep(500); if(SAVE_HOOK!=null){ SAVE_HOOK.isAlive(); }else{ System.out.println("no,i am dead."); } } }结果如下：
FinalizeEscapeGC类覆盖了finalize方法，所以在GC将SAVE_HOOK第一次标记为垃圾后的筛选中认为finalize有必要执行。在覆盖的finalize方法中，将自己赋值给了类的变量SAVE_HOOK，成功拯救自己，第一次没有被收集。但是第二次虽然代码相同，但是由于虚拟机已经执行过finalize方法了，GC不认为有必要执行，在第二次标记中也标记为垃圾，所以没有能拯救自己，被当做垃圾收集了。
java中的引用
其实Java中的引用一共有四种。这是JDK 1.2 之后对引用概念的扩充，分别是强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference），这四种引用的强度依次逐渐减弱。
（1）强引用
强引用就是程序中普遍存在的，类似“Object obj=new Object()”这类的引用，只要强引用还存在，垃圾回收器就不会回收被引用的对象。
（2）软引用
软引用用来描述一些还有用但不是必须的对象。对于软引用关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象列入回收范围进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。SoftReference类来实现软引用。
（3）弱引用
弱引用也用来描述非必须的对象，但是强度比软引用还弱，被引用的对象只能存活到下一次垃圾收集之前。当下一次垃圾收集器工作时，不论内存是否足够，都会回收这些对象。WeakReference类实现了弱引用。
（4）虚引用
虚引用是最弱的一种引用，也叫幽灵引用或幻影引用。一个对象是否有虚引用存在不会对其生存时间产生影响，也无法通过虚引用来取得一个对象实例。虚引用的唯一目的就是当被虚引用关联的对象被收集器收集时收到一个系统通知。PhantomReference类实现了虚引用。
总结一下平常遇到的比较常见的将对象判定为可回收对象的情况：1）显示地将某个引用赋值为null或者将已经指向某个对象的引用指向新的对象，比如下面的代码：
Object obj = new Object(); obj = null; Object obj1 = new Object(); Object obj2 = new Object(); obj1 = obj2;
2）局部引用所指向的对象，比如下面这段代码：
void fun() { ..... for(int i=0;i<10;i++) { Object obj = new Object(); System.out.println(obj.getClass()); } }循环每执行完一次，生成的Object对象都会成为可回收的对象。
3）只有弱引用与其关联的对象，比如：
WeakReference<String> wr = new WeakReference<String>(new String("world"));
二.典型的垃圾收集算法
在确定了哪些垃圾可以被回收后，垃圾收集器要做的事情就是开始进行垃圾回收，但是这里面涉及到一个问题是：如何高效地进行垃圾回收。由于Java虚拟机规范并没有对如何实现垃圾收集器做出明确的规定，因此各个厂商的虚拟机可以采用不同的方式来实现垃圾收集器，所以在此只讨论几种常见的垃圾收集算法的核心思想。1.Mark-Sweep（标记-清除）算法
这是最基础的垃圾回收算法，之所以说它是最基础的是因为它最容易实现，思想也是最简单的。标记-清除算法分为两个阶段：标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。具体过程如下图所示：
从图中可以很容易看出标记-清除算法实现起来比较容易，但是有一个比较严重的问题就是容易产生内存碎片，碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作。
2.Copying（复制）算法
为了解决Mark-Sweep算法的缺陷，Copying算法就被提了出来。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。具体过程如下图所示：
这种算法虽然实现简单，运行高效且不容易产生内存碎片，但是却对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。
很显然，Copying算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么Copying算法的效率将会大大降低。
3.Mark-Compact（标记-整理）算法
为了解决Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。具体过程如下图所示：
4.Generational Collection（分代收集）算法
分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。
Java 中的堆是 JVM 所管理的最大的一块内存空间，主要用于存放各种类的实例对象。在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )。老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。新生代 ( Young ) 又被划分为三个区域：Eden、From Survivor、To Survivor。这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象，包括内存的分配以及回收。
JVM 每次只会使用 Eden 和其中的一块 Survivor 区域来为对象服务，所以无论什么时候，总是有一块 Survivor 区域是空闲着的。因此，新生代实际可用的内存空间为 9/10 ( 即90% )的新生代空间。新生代垃圾回收采用复制算法，清理的频率比较高。如果新生代在若干次清理（可以进行设置）中依然存活，则移入老年代，有的内存占用比较大的直接进入老年代。老年代使用标记整理算法，清理的频率比较低。
目前大部分垃圾收集器对于新生代都采取Copying算法，因为新生代中每次垃圾回收都要回收大部分对象，也就是说需要复制的操作次数较少，但是实际中并不是按照1：1的比例来划分新生代的空间的，一般来说是将新生代划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden空间和其中的一块Survivor空间，当进行回收时，将Eden和Survivor中还存活的对象复制到另一块Survivor空间中，然后清理掉Eden和刚才使用过的Survivor空间。
而由于老年代的特点是每次回收都只回收少量对象，一般使用的是Mark-Compact算法。
注意，在堆区之外还有一个代就是永久代（Permanet Generation），它用来存储class类、常量、方法描述等。对永久代的回收主要回收两部分内容：废弃常量和无用的类。
这种回收方式用了程序的一种特性：大部分对象会从产生开始在很短的时间内变成垃圾，而存在的很长时间的对象往往都有较长的生命周期。高频对新生成的对象进行回收，称为「小回收」，低频对所有对象回收，称为「大回收」。每一次「小回收」过后，就把存活下来的对象归为「老生代」，「小回收」的时候，遇到老生代直接跳过。大多数分代回收算法都采用的「复制收集」方法，因为小回收中垃圾的比例较大。
这种方式存在一个问题：如果在某个新生代的对象中，存在「老生代」的对象对它的引用，它就不是垃圾了，那么怎么制止「小回收」对其回收呢？这里用到了一中叫做写屏障的方式。
三.典型的垃圾收集器
垃圾收集算法是 内存回收的理论基础，而垃圾收集器就是内存回收的具体实现。下面介绍一下HotSpot（JDK 7)虚拟机提供的几种垃圾收集器，用户可以根据自己的需求组合出各个年代使用的收集器。
（1）Serial收集器
Serial收集器是最基本的、历史最悠久的收集器，曾经是JDK 1.3.1之前虚拟机的新生代收集的唯一选择。Serial这个名字揭示了这是一个单线程的垃圾收集器，特点如下：
- 仅仅使用一个线程完成垃圾收集工作；
- 在垃圾收集时必须暂停其他所有的工作线程，知道垃圾收集结束；
- Stop the World是在用户不可见的情况下执行的，会造成某些应用响应变慢；
- 使用复制算法；
Serial收集器的工作流程如下图：
虽然如此，Serial收集器依然是虚拟机运行在Client模式下的默认新生代收集器。它的优点同样明显：简单而高效（单个线程相比），并且由于没有线程交互的开销，专心做垃圾收集自然课获得最高的单线程效率。在一般情况下，垃圾收集造成的停顿时间可以控制在几十毫秒甚至一百多毫秒以内，还是可以接受的。
（2）ParNew收集器
ParNew收集器其实是Serial收集器的多线程版本，与Serial不同的地方就是在垃圾收集过程中使用多个线程，剩下的所有行为包括控制参数、收集算法、Stop the World、对象分配规则和回收策略等都一样。ParNew收集器也使用复制算法。ParNew收集器的工作流程如下图：
ParNew收集器看似没有多大的创新之处，但却是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为，除了Serial收集器外，目前只有ParNew收集器能够与CMS收集器配合工作，而CMS收集器是HotSpot在JDK 1.5时期推出的具有划时代意义的垃圾收集器（后面会介绍到）。
ParNew收集器在单个线程的情况下由于线程交互的开销没有Serial收集器的效果好。不过，随着CPU个数的增加，它对于GC时系统资源的有效利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同。可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
（3）Parallel Scavenge收集器
Parallel Scavenge收集器和ParNew类似，是一个新生代收集器，使用复制算法，又是并行的多项成收集器。不过和ParNew不同的是，Parallel Scavenge收集器的关注点不同。
CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目的则是达到一个可控制的吞吐量。吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+运行垃圾收集时间）。如果虚拟机一共运行100分钟，垃圾收集运行了1分钟，那么吞吐量就是99%。
停顿时间越短就越适合与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效的利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
Parallel Scavenge收集器提供了两个参数来精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。
MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽可能在给定时间内完成垃圾收集。不过垃圾收集时间的缩短是以牺牲吞吐量和新生代空间为代价的，短的垃圾收集时间会导致更加频繁的垃圾收集行为，从而导致吞吐量的降低。
GCTimeRatio参数的值是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。如果设置为19，那允许的最大GC时间就是总时间的5%（1/(1+19)）。默认是99，也就是允许最大1%的垃圾收集时间。
Parallel Scavenge收集器也叫吞吐量优先收集器，它还有一个参数-XX:UseAdaptiveSizePolicy，这是一个开关参数，当这个参数打开后，就不需要手工指定新生代的大小（-Xmn）、Eden和Survivor的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最适合的停顿时间或最大的吞吐量，这叫GC自适应的调节策略。这也是Parallel Scavenge收集器和ParNew收集器的一个重要区别。
（4）Serial Old收集器
Serial Old是Serial的老年版本，在Serial的工作流程图中可以看到，Serial Old收集器也是一个单线程收集器，使用“标记-整理”算法。这个收集器主要给Client模式下的虚拟机使用。如果在Serve模式下，它有两个用途：一个是在JDK 1.5之前的版本中与Parallel Scavenge收集器搭配使用；另一个就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。这个收集器的工作流程在Serial的后半部分有所体现。
（5）Parallel Old收集器
Parallel Old收集器是Parallel Scavenge收集器的老年版本，它也使用多线程和“标记-整理”算法。这个收集器是在JDK 1.6开始提供。
在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器的组合。Parallel Old收集器的工作流程如下：
（6）CMS收集器
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。在重视响应速度和用户体验的应用中，CMS应用很多。
CMS收集器使用“标记-清除”算法，运作过程比较复杂，分为4个步骤：
- 初始标记（CMS initial mark）
- 并发标记（CMS Concurrent mark）
- 重新标记（CMS remark）
- 并发清除（CMS Concurrent Sweep）
其中，初始标记和并发标记仍然需要Stop the World、初始标记仅仅标记一下GC Roots能直接关联到的对象，速度很快，并发标记就是进行GC RootsTracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段长，但远比并发标记的时间短。
由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以整体上说，CMS收集器的内存回收过程是与用户线程一共并发执行的。下图是流程图：
CMS的优点就是并发收集、低停顿，是一款优秀的收集器。不过，CMS也有缺点，如下：
- CMS收集器对CPU资源非常敏感。CMS默认启动的回收线程数是（CPU数量+3）/4，当CPU个数大于4时，垃圾收集线程使用不少于25%的CPU资源，当CPU个数不足时，CMS对用户程序的影响很大；
- CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC；
- CMS使用标记-清除算法，会产生内存碎片；
（7）G1收集器
G1（Garbage first）收集器是最先进的收集器之一，是面向服务端的垃圾收集器。与其他收集器相比，G1收集器有如下优点：
- 并行与并发：有些收集器需要停顿的过程G1仍然可以通过并发的方式让用户程序继续执行；
- 分代收集：可以不使用其他收集器配合管理整个Java堆；
- 空间整合：使用标记-整理算法，不产生内存碎片；
- 可预测的停顿：G1除了降低停顿外，还能建立可预测的停顿时间模型；
G1中也有分代的概念，不过使用G1收集器时，Java堆的内存布局与其他收集器有很大的差别，它将整个Java堆划分为多个大小相等的独立区域（Region），G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里垃圾堆积的价值大小（回收所获得的空间大小以及回收所需要的时间的经验值），在后台维护一个优先列表，每次优先收集价值最大的那个Region。这样就保证了在有限的时间内尽可能提高效率。
G1收集器的大致步骤如下：
- 初始标记（Initial mark）
- 并发标记（Concurrent mark）
- 最终标记（Final mark）
- 筛选回收（Live Data Counting and Evacuation）
收集器的流程如下图：
就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合：
- 服务端多核CPU、JVM内存占用较大的应用（至少大于4G）
- 应用在运行过程中会产生大量内存碎片、需要经常压缩空间
- 想要更可控、可预期的GC停顿周期；防止高并发下应用雪崩现象
下面补充一下关于内存分配方面的东西：
对象的内存分配，往大方向上讲就是在堆上分配，对象主要分配在新生代的Eden Space和From Space，少数情况下会直接分配在老年代。如果新生代的Eden Space和From Space的空间不足，则会发起一次GC，如果进行了GC之后，Eden Space和From Space能够容纳该对象就放在Eden Space和From Space。在GC的过程中，会将Eden Space和From Space中的存活对象移动到To Space，然后将Eden Space和From Space进行清理。如果在清理的过程中，To Space无法足够来存储某个对象，就会将该对象移动到老年代中。在进行了GC之后，使用的便是Eden space和To Space了，下次GC时会将存活对象复制到From Space，如此反复循环。当对象在Survivor区躲过一次GC的话，其对象年龄便会加1，默认情况下，如果对象年龄达到15岁，就会移动到老年代中。
一般来说，大对象会被直接分配到老年代，所谓的大对象是指需要大量连续存储空间的对象，最常见的一种大对象就是大数组，比如：
byte[] data = new byte[4*1024*1024]
这种一般会直接在老年代分配存储空间。
当然分配的规则并不是百分之百固定的，这要取决于当前使用的是哪种垃圾收集器组合和JVM的相关参数。
参考：