MinorGC 和 FullGC的理解

1.GC回收机制熟悉么，分代算法知道么？
2.了解 Java 虚拟机的垃圾回收算法？

从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。 Major GC 是清理永久代。Full GC 是清理整个堆空间—包括年轻代和永久代。
> Android GC
Android GC 原理探究- http://geek.csdn.net/news/detail/193654

> Java中的GC是什么? 为什么要有GC?
GC目的：回收堆内存中不再使用的对象，释放资源
回收时间：当对象永久地失去引用后，系统会在合适的时候回收它所占的内存。

GC System.gc()或Runtime.getRuntime().gc()，
  忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃，Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的。垃圾回收可以有效的防止内存泄露，有效的使用可以使用的内存。
 采用“分代式垃圾收集”。这种方法会跟Java对象的生命周期将堆内存划分为不同的区域，在垃圾收集过程中，可能会将对象移动到不同区域： 
 - 伊甸园（Eden）：这是对象最初诞生的区域，并且对大多数对象来说，这里是它们唯一存在过的区域。 
 - 幸存者乐园（Survivor）：从伊甸园幸存下来的对象会被挪到这里。 
 - 终身颐养园（Tenured）：这是足够老的幸存对象的归宿。年轻代收集（Minor-GC）过程是不会触及这个地方的。当年轻代收集不能把对象放进终身颐养园时，就会触发一次完全收集（Major-GC），这里可能还会牵扯到压缩，以便为大对象腾出足够的空间。

在C/C++中，释放无用变量内存空间的事情要由程序员自己来解决。
  Java有了GC，就不需要程序员去人工释放内存空间。当Java虚拟机发觉内存资源紧张的时候，就会自动地去清理无用变量所占用的内存空间。当然，如果需要，程序员可以在Java程序中显式地使用System.gc()来强制进行一次立即的内存清理。 因为显式声明是做堆内存全扫描，也就是 Full GC，是需要停止所有的活动的（Stop The World Collection），你的应用能承受这个吗？而其显示调用System.gc()只是给虚拟机一个建议，不一 定会执行，因为System.gc()在一个优先级很低的线程中执行。
  java的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的，java语言没有提供释放已分配内存的俄显示操作方法。在应用程序中，只要某对象变得不可达，也就是没有根（root）引用该对象，这个对象就会成为垃圾回收器的目标。

GC的基本原理:
 1.对于程序员来说，用new关键字即在堆中分配了内存，我们称之为“可达”。对于GC来说，只要所有被引用的对象为null时，我们称之为“不可达”，就将进行内存的回收。
 2.当一个对象被创建时，GC开始监控这个对象的大小、内存地址及使用情况。GC采用有向图的方式记录和管理堆(heap)中的所有对象，通过这种方式可以明确哪些对象是可达的，哪些不是。当确定为不可达时，则对其进行回收。
 3.保证GC在不同平台的实现问题，java规范对其很多行为没有进行严格的规定。对于采用什么算法，什么时候进行回收等。

-- GC收集器有哪些?

1.serial收集器
单线程，工作时必须暂停其他工作线程。多用于client机器上，使用复制算法
2.ParNew收集器
serial收集器的多线程版本，server模式下虚拟机首选的新生代收集器。复制算法
3.Parallel Scavenge收集器
复制算法，可控制吞吐量的收集器。吞吐量即有效运行时间。
4.Serial Old收集器
serial的老年代版本，使用整理算法。
5.Parallel Old收集器
第三种收集器的老年代版本，多线程，标记整理
6.CMS收集器
目标是最短回收停顿时间。7.G1收集器,基本思想是化整为零，将堆分为多个Region，优先收集回收价值最大的Region。

> Java GC，GC 算法，GC机制
内存分配过程为（来源于《成为JavaGC专家part I》-http://www.importnew.com/1993.html
成为JavaGC专家Part II — 如何监控Java垃圾回收机制-http://www.importnew.com/2057.html
JDK5.0垃圾收集优化之 - http://calvin.iteye.com/blog/91905
三大Java 虚拟机垃圾回收机制的比较（HotSpot, JRockit, IBM JVM）- https://blog.csdn.net/ZYC88888/article/details/70918799
垃圾回收器,如何判断对象是否存活- http://blog.csdn.net/TyroneRenekton/article/details/59114835?ref=myread
JVM初探- 内存分配、GC原理与垃圾收集器-- http://blog.csdn.net/zjf280441589/article/details/53946312
深入理解JVM之一：Java内存区域: https://yq.aliyun.com/articles/14408#

-- 在Java中，它的内存管理包括两方面：内存分配（创建Java对象的时候）和内存回收。了解JVM，才能写出更高效，充分利用有限的内存的程序。
  Java垃圾回收主要做的是两件事：1）内存回收； 2）碎片整理。

内存管理小技巧:
　　1）尽量使用直接量，eg：String javaStr = "小学徒的成长历程";
　　2）使用StringBuilder和StringBuffer进行字符串连接等操作;
　　3）尽早释放无用对象;
　　4）尽量少使用静态变量;
　　5）缓存常用的对象:可以使用开源的开源缓存实现，eg：OSCache，Ehcache;
　　6）尽量不使用finalize()方法;
　　7）在必要的时候可以考虑使用软引用SoftReference。

-- GC回收机制算法：分代复制垃圾回收和标记垃圾回收，增量垃圾回收。

学习Java GC机制，可以帮助我们在日常工作中排查各种内存溢出或泄露问题，解决性能瓶颈，达到更高的并发量，写出更高效的程序。我们将从4个方面学习Java GC机制：

1，内存是如何分配的；

2，如何保证内存不被错误回收（即：哪些内存需要回收）；

3，在什么情况下执行GC以及执行GC的方式；

4，如何监控和优化GC机制。

--  了解Java GC机制，必须先清楚在JVM中内存区域的划分。
在Java运行时的数据区里，JVM管理的内存区域分为几个模块：
  1，程序计数器（Program Counter Register）：程序计数器是一个比较小的内存区域，用于指示当前线程所执行的字节码执行到了第几行，可以理解为是当前线程的行号指示器。字节码解释器在工作时，会通过改变这个计数器的值来取下一条语句指令。
 每个程序计数器只用来记录一个线程的行号，所以它是线程私有（一个线程就有一个程序计数器）的。
   如果程序执行的是一个Java方法，则计数器记录的是正在执行的虚拟机字节码指令地址；如果正在执行的是一个本地（native，由C语言编写 完成）方法，则计数器的值为Undefined，由于程序计数器只是记录当前指令地址，所以不存在内存溢出的情况，因此，程序计数器也是所有JVM内存区 域中唯一一个没有定义OutOfMemoryError的区域。

2，虚拟机栈（JVM Stack）：一个线程的每个方法在执行的同时，都会创建一个栈帧（Statck Frame），栈帧中存储的有局部变量表、操作站、动态链接、方法出口等，当方法被调用时，栈帧在JVM栈中入栈，当方法执行完成时，栈帧出栈。
   局部变量表中存储着方法的相关局部变量，包括各种基本数据类型，对象的引用，返回地址等。在局部变量表中，只有long和double类型会占用2个局部变量空间（Slot，对于32位机器，一个Slot就是32个bit），其它都是1个Slot。需要注意的是，局部变量表是在编译时就已经确定 好的，方法运行所需要分配的空间在栈帧中是完全确定的，在方法的生命周期内都不会改变。
   虚拟机栈中定义了两种异常，如果线程调用的栈深度大于虚拟机允许的最大深度，则抛出StatckOverFlowError（栈溢出）；不过多 数Java虚拟机都允许动态扩展虚拟机栈的大小(有少部分是固定长度的)，所以线程可以一直申请栈，知道内存不足，此时，会抛出 OutOfMemoryError（内存溢出）。
   每个线程对应着一个虚拟机栈，因此虚拟机栈也是线程私有的。

3，本地方法栈（Native Method Statck）：本地方法栈在作用，运行机制，异常类型等方面都与虚拟机栈相同，唯一的区别是：虚拟机栈是执行Java方法的，而本地方法栈是用来执行native方法的，在很多虚拟机中（如Sun的JDK默认的HotSpot虚拟机），会将本地方法栈与虚拟机栈放在一起使用。
  本地方法栈也是线程私有的。

4，堆区（Heap）：堆区是理解Java GC机制最重要的区域，没有之一。在JVM所管理的内存中，堆区是最大的一块，堆区也是Java GC机制所管理的主要内存区域，堆区由所有线程共享，在虚拟机启动时创建。堆区的存在是为了存储对象实例，原则上讲，所有的对象都在堆区上分配内存（不过现代技术里，也不是这么绝对的，也有栈上直接分配的）。
  一般的，根据Java虚拟机规范规定，堆内存需要在逻辑上是连续的（在物理上不需要），在实现时，可以是固定大小的，也可以是可扩展的，目前主流的虚拟机堆区都是可扩展的。如果在执行垃圾回收之后，仍没有足够的内存分配，也不能再扩展，将会抛出OutOfMemoryError:Java heap space异常。
    “Java内存分配机制”。

5，方法区（Method Area）：在Java虚拟机规范中，将方法区作为堆的一个逻辑部分来对待，但事实上，方法区并不是堆（Non-Heap）；另外，不少人的博客中，将Java GC的分代收集机制分为3个代：青年代，老年代，永久代，这些作者将方法区定义为“永久代”，这是因为，对于之前的HotSpot Java虚拟机的实现方式中，将分代收集的思想扩展到了方法区，并将方法区设计成了永久代。不过，除HotSpot之外的多数虚拟机，并不将方法区当做永久代，HotSpot本身，也计划取消永久代。本文中，由于笔者主要使用Oracle JDK6.0，因此仍将使用永久代一词。
  方法区是各个线程共享的区域，用于存储已经被虚拟机加载的类信息（即加载类时需要加载的信息，包括版本、field、方法、接口等信息）、final常量、静态变量、编译器即时编译的代码等。
  方法区在物理上也不需要是连续的，可以选择固定大小或可扩展大小，并且方法区比堆还多了一个限制：可以选择是否执行垃圾收集。一般的，方法区上 执行的垃圾收集是很少的，这也是方法区被称为永久代的原因之一（HotSpot），但这也不代表着在方法区上完全没有垃圾收集，其上的垃圾收集主要是针对常量池的内存回收和对已加载类的卸载。
  在方法区上进行垃圾收集，条件苛刻而且相当困难，效果也不令人满意，所以一般不做太多考虑，可以留作以后进一步深入研究时使用。
  在方法区上定义了OutOfMemoryError:PermGen space异常，在内存不足时抛出。
  运行时常量池（Runtime Constant Pool）是方法区的一部分，用于存储编译期就生成的字面常量、符号引用、翻译出来的直接引用（符号引用就是编码是用字符串表示某个变量、接口的位置，直接引用就是根据符号引用翻译出来的地址，将在类链接阶段完成翻译）；运行时常量池除了存储编译期常量外，也可以存储在运行时间产生的常量（比如String类的intern()方法，作用是String维护了一个常量池，如果调用的字符“abc”已经在常量池中，则返回池中的字符串地址，否则，新建一个常量加入池中，并返回地址）。

6，直接内存（Direct Memory）：直接内存并不是JVM管理的内存，可以这样理解，直接内存，就是 JVM以外的机器内存，比如，你有4G的内存，JVM占用了1G，则其余的3G就是直接内存，JDK中有一种基于通道（Channel）和缓冲区 （Buffer）的内存分配方式，将由C语言实现的native函数库分配在直接内存中，用存储在JVM堆中的DirectByteBuffer来引用。 由于直接内存收到本机器内存的限制，所以也可能出现OutOfMemoryError的异常。

-- Java对象的访问方式。一般来说，一个Java的引用访问涉及到3个内存区域：JVM栈，堆，方法区。
以最简单的本地变量引用：Object obj = new Object()为例：
  Object obj表示一个本地引用，存储在JVM栈的本地变量表中，表示一个reference类型数据；
  new Object()作为实例对象数据存储在堆中；
  堆中还记录了Object类的类型信息（接口、方法、field、对象类型等）的地址，这些地址所执行的数据存储在方法区中；
在Java虚拟机规范中，对于通过reference类型引用访问具体对象的方式并未做规定.

--  Java GC机制：

JVM 内置的通用垃圾回收原则。堆内存划分为 Eden、Survivor(年轻代) ， Tenured/Old (老年代)空间：
1.Minor GC
    从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。但是，当发生Minor GC事件的时候，有一些有趣的地方需要注意到：
    当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。
   质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就 是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。
  所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。

2.Major GC vs Full GC
    Major GC 是清理永久代。Full GC 是清理整个堆空间—包括年轻代和永久代。
很不幸，实际上它还有点复杂且令人困惑。首先，许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的。另一方面，许多现代垃圾收集机制会清理部分永久代空间，所以使用“cleaning”一词只是部分正确。
   这使得我们不用去关心到底是叫 Major GC 还是 Full GC，大家应该关注当前的 GC 是否停止了所有应用程序的线程，还是能够并发的处理而不用停掉应用程序的线程。

这种混乱甚至内置到 JVM 标准工具。下面一个例子很好的解释了我的意思。让我们比较两个不同的工具 Concurrent Mark 和 Sweep collector (-XX:+UseConcMarkSweepGC)在 JVM 中运行时输出的跟踪记录。
   关于JVM，需要说明一下的是，目前使用最多的Sun公司的JDK中，自从 1999年的JDK1.2开始直至现在仍在广泛使用的JDK6，其中默认的虚拟机都是HotSpot。2009年，Oracle收购Sun，加上之前收购 的EBA公司，Oracle拥有3大虚拟机中的两个：JRockit和HotSpot，Oracle也表明了想要整合两大虚拟机的意图，但是目前在新发布 的JDK7中，默认的虚拟机仍然是HotSpot，因此本文中默认介绍的虚拟机都是HotSpot，相关机制也主要是指HotSpot的GC机制。

-- GC机制的基本算法是：分代收集

新生代：一般是指大批对象产生的快，消亡的也快；老生代：一般是指大批对象产生后，不容易消。
-- 年轻代：
　 新生代的主要垃圾回收方法，在新生代中，使用“停止-复制”算法进行清理，将新生代内存分为2部分，1部分 Eden区较大，1部分Survivor比较小，并被划分为两个等量的部分。每次进行清理时，将Eden区和一个Survivor中仍然存活的对象拷贝到 另一个Survivor中，然后清理掉Eden和刚才的Survivor。
    这里也可以发现，停止复制算法中，用来复制的两部分并不总是相等的（传统的停止复制算法两部分内存相等，但新生代中使用1个大的Eden区和2个小的Survivor区来避免这个问题）
　　由于绝大部分的对象都是短命的，甚至存活不到Survivor中，所以，Eden区与Survivor的比例较大，HotSpot默认是 8:1，即分别占新生代的80%，10%，10%。如果一次回收中，Survivor+Eden中存活下来的内存超过了10%，则需要将一部分对象分配到 老年代。用-XX:SurvivorRatio参数来配置Eden区域Survivor区的容量比值，默认是8，代表Eden：Survivor1：Survivor2=8:1:1.

-- 老年代：
    老年代存储的对象比年轻代多得多，而且不乏大对象，对老年代进行内存清理时，如果使用停止-复制算法，则相当低效。一般，老年代用的算法是标记-整理算法，即：标记出仍然存活的对象（存在引用的），将所有存活的对象向一端移动，以保证内存的连续。
     在发生Minor GC时，虚拟机会检查每次晋升进入老年代的大小是否大于老年代的剩余空间大小，如果大于，则直接触发一次Full GC，否则，就查看是否设 置了-XX:+HandlePromotionFailure（允许担保失败），如果允许，则只会进行MinorGC，此时可以容忍内存分配失败；如果不允许，则仍然进行Full GC（这代表着如果设置-XX:+Handle PromotionFailure，则触发MinorGC就会同时触发Full GC，哪怕老年代还有很多内存，所以，最好不要这样做）。
    方法区（永久代），永久代的回收有两种：常量池中的常量，无用的类信息，常量的回收很简单，没有引用了就可以被回收。对于无用的类进行回收，必须保证3点：1.类的所有实例都已经被回收；2.加载类的ClassLoader已经被回收。3.类对象的Class对象没有被引用（即没有通过反射引用该类的地方）
   永久代的回收并不是必须的，可以通过参数来设置是否对类进行回收。HotSpot提供-Xnoclassgc进行控制，使用-verbose，-XX:+TraceClassLoading、-XX:+TraceClassUnLoading可以查看类加载和卸载信息：
     -verbose、-XX:+TraceClassLoading可以在Product版HotSpot中使用；
     -XX:+TraceClassUnLoading需要fastdebug版HotSpot支持。

-- 垃圾收集器

在介绍垃圾收集器之前，需要明确一点，就是在新生代采用的停止复制算法中，“停 止（Stop-the-world）”的意义是在回收内存时，需要暂停其他所有线程的执行。这个是很低效的，现在的各种新生代收集器越来越优化这一点，但仍然只是将停止的时间变短，并未彻底取消停止。

1. Serial收集器：新生代收集器，使用停止复制算法，使用一个线程进行GC，其它工作线程暂停。使用-XX:+UseSerialGC可以使用Serial+Serial Old模式运行进行内存回收（这也是虚拟机在Client模式下运行的默认值）
  2. ParNew收集器：新生代收集器，使用停止复制算法，Serial收集器的多线程版，用多个线程进行GC，其它工作线程暂停，关注缩短垃圾收集时间。使用-XX:+UseParNewGC开关来控制使用ParNew+Serial Old收集器组合收集内存；使用-XX:ParallelGCThreads来设置执行内存回收的线程数。
  3. Parallel Scavenge 收集器：新生代收集器，使用停止复制算法，关注CPU吞吐量，即运行用户代码的时间/总时间，比如：JVM运行100分钟，其中运行用户代码99分钟，垃圾收集1分钟，则吞吐量是99%，这种收集器能最高效率的利用CPU，适合运行后台运算（关注缩短垃圾收集时间的收集器，如CMS，等待时间很少，所以适 合用户交互，提高用户体验）。使用-XX:+UseParallelGC开关控制使用 Parallel Scavenge+Serial Old收集器组合回收垃圾（这也是在Server模式下的默认值）；使用-XX:GCTimeRatio来设置用户执行时间占总时间的比例，默认99，即 1%的时间用来进行垃圾回收。使用-XX:MaxGCPauseMillis设置GC的最大停顿时间（这个参数只对Parallel Scavenge有效）
  4. Serial Old收集器：老年代收集器，单线程收集器，使用标记整理（整理的方法是Sweep清理和Compact压缩，清理是将废弃的对象干掉，只留幸存的对象，压缩是将移动对象，将空间填满保证内存分为2块，一块全是对象，一块空闲）算法，使用单线程进行GC，其它工作线程暂停（注意，在老年代中进行标 记整理算法清理，也需要暂停其它线程），在JDK1.5之前，Serial Old收集器与ParallelScavenge搭配使用。
  5. Parallel Old收集器：老年代收集器，多线程，多线程机制与Parallel Scavenge差不错，使用标记整理（与Serial Old不同，这里的整理是Summary汇总和Compact压缩，汇总的意思就是将幸存的对象复制到预先准备好的区域，而不是像Sweep（清 理）那样清理废弃的对象）算法，在Parallel Old执行时，仍然需要暂停其它线程。Parallel Old在多核计算中很有用。Parallel Old出现后（JDK 1.6），与Parallel Scavenge配合有很好的效果，充分体现Parallel Scavenge收集器吞吐量优先的效果。使用-XX:+UseParallelOldGC开关控制使用Parallel Scavenge +Parallel Old组合收集器进行收集。
  6. CMS（Concurrent Mark Sweep）收集器：老年代收集器，致力于获取最短回收停顿时间，使用标记清除算法，多线程，优点是并发收集（用户线程可以和GC线程同时工作），停顿小。使用-XX:+UseConcMarkSweepGC进行ParNew+CMS+Serial Old进行内存回收，优先使用ParNew+CMS（原因见后面），当用户线程内存不足时，采用备用方案Serial Old收集。
  CMS收集的方法是：先3次标记，再1次清除，3次标记中前两次是初始标记和重新标记（此时仍然需要停止（stop the world））， 初始标记（Initial Remark）是标记GC Roots能关联到的对象（即有引用的对象），停顿时间很短；并发标记（Concurrent remark）是执行GC Roots查找引用的过程，不需要用户线程停顿；重新标记（Remark）是在初始标记和并发标记期间，有标记变动的那部分仍需要标记，所以加上这一部分 标记的过程，停顿时间比并发标记小得多，但比初始标记稍长。在完成标记之后，就开始并发清除，不需要用户线程停顿。
  所以在CMS清理过程中，只有初始标记和重新标记需要短暂停顿，并发标记和并发清除都不需要暂停用户线程，因此效率很高，很适合高交互的场合。
  CMS也有缺点，它需要消耗额外的CPU和内存资源，在CPU和内存资源紧张，CPU较少时，会加重系统负担（CMS默认启动线程数为(CPU数量+3)/4）。
  另外，在并发收集过程中，用户线程仍然在运行，仍然产生内存垃圾，所以可能产生“浮动垃圾”，本次无法清理，只能下一次Full GC才清理，因此在GC期间，需要预留足够的内存给用户线程使用。所以使用CMS的收集器并不是老年代满了才触发Full GC，而是在使用了一大半（默认68%，即2/3，使用-XX:CMSInitiatingOccupancyFraction来设置）的时候就要进行Full GC，如果用户线程消耗内存不是特别大，可以适当调高-XX:CMSInitiatingOccupancyFraction以降低GC次数，提高性能，如果预留的用户线程内存不够，则会触发Concurrent Mode Failure，此时，将触发备用方案：使用Serial Old 收集器进行收集，但这样停顿时间就长了，因此-XX:CMSInitiatingOccupancyFraction不宜设的过大。
  还有，CMS采用的是标记清除算法，会导致内存碎片的产生，可以使用-XX：+UseCMSCompactAtFullCollection来设置是否在Full GC之后进行碎片整理，用-XX：CMSFullGCsBeforeCompaction来设置在执行多少次不压缩的Full GC之后，来一次带压缩的Full GC。
G1收集器：在JDK1.7中正式发布，与现状的新生代、老年代概念有很大不同，目前使用较少，不做介绍。
注意并发（Concurrent）和并行（Parallel）的区别：
     并发是指用户线程与GC线程同时执行（不一定是并行，可能交替，但总体上是在同时执行的），不需要停顿用户线程（其实在CMS中用户线程还是需要停顿的，只是非常短，GC线程在另一个CPU上执行）；
     并行收集是指多个GC线程并行工作，但此时用户线程是暂停的；所以，Serial和Parallel收集器都是并行的，而CMS收集器是并发的.

-- 垃圾回收器经典算法：
  1）Reference counting（引用计数）
基本思想是：当对象创建并赋值时该对象的引用计数器置1，每当对象给任意变量赋值时，引用记数＋1；一旦退出作用域则引用记数－1。一旦引用记数变为0，则该对象可以被垃圾回收。
引用记数有其相应的优势：对程序的执行来说，每次操作只需要花费很小块的时间。这对于不能被过长中断的实时系统来说有着天然的优势。
但也有其不足：不能够检测到环（两个对象的互相引用）；同时在每次增加或者减少引用记数的时候比较费时间。在现代的垃圾回收算法中，引用记数已经不再使用。
  2）Mark-sweep（标记清理）
基本思想是：每次从根集出发寻找所有的引用（称为活对象），每找到一个，则对其做出标记，当追踪完成之后，所有的未标记对象便是需要回收的垃圾。
也叫追踪算法，基于标记并清除。这个垃圾回收步骤分为两个阶段：在标记阶段，垃圾回收器遍历整棵引用树并标记每一个遇到的对象。在清除阶段，未标记的对象被释放，并使其在内存中可用。
  3）Copying collection（复制收集）
基本思想是：将内存划分为两块，一块是当前正在使用；另一块是当前未用。每次分配时使用当前正在使用内存，当无可用内存时，对该区域内存进行标记，并将标记的对象全部拷贝到当前未用内存区，这是反转两区域，即当前可用区域变为当前未用，而当前未用变为当前可用，继续执行该算法。
拷贝算法需要停止所有的程序活动，然后开始冗长而繁忙的copy工作。这点是其不利的地方。
  近年来还有两种算法：
  4）Generational garbage collection（分代）
其思想依据是：
  (1) 被大多数程序创建的大多数对象有着非常短的生存期。
  (2) 被大多数程序创建的部分对象有着非常长的生存期。
简单拷贝算法的主要不足是它们花费了更多的时间去拷贝了一些长期生存的对象。
而分代算法的基本思想是：将内存区域分两块（或更多），其中一块代表年轻代，另一块代表老的一代。针对不同的特点，对年轻一代的垃圾收集更为频繁，对老代的收集则较少，每次经过年轻一代的垃圾回收总会有未被收集的活对象，这些活对象经过收集之后会增加成熟度，当成熟度到达一定程度，则将其放进老代内存块中。
分代算法很好的实现了垃圾回收的动态性，同时避免了内存碎片，是目前许多JVM使用的垃圾回收算法。
  5）Conservative garbage collection（保守）