JVM介绍

1、JVM结构图

     

1）类加载子系统负责从文件系统或者网络中加载Class信息，加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中可能还会存放运行时常量池信息，包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）。

2）java堆在虚拟机启动的时候建立，它是java程序最主要的内存工作区域。几乎所有的java对象实例都存放在java堆中。堆空间是所有线程共享的，这是一块与java应用密切相关的内存空间。

3）java的NIO库允许java程序使用直接内存。直接内存是在java堆外的、直接向系统申请的内存空间。通常访问直接内存的速度会优于java堆。因此出于性能的考虑，读写频繁的场合可能会考虑使用直接内存。由于直接内存在java堆外，因此它的大小不会直接受限于Xmx指定的最大堆大小，但是系统内存是有限的，java堆和直接内存的总和依然受限于操作系统能给出的最大内存。

4）垃圾回收系统是java虚拟机的重要组成部分，垃圾回收器可以对方法区、java堆和直接内存进行回收。其中，java堆是垃圾收集器的工作重点。和C/C++不同，java中所有的对象空间释放都是隐式的，也就是说，java中没有类似free()或者delete()这样的函数释放指定的内存区域。对于不再使用的垃圾对象，垃圾回收系统会在后台默默工作，默默查找、标识并释放垃圾对象，完成包括java堆、方法区和直接内存中的全自动化管理。

5）每一个java虚拟机线程都有一个私有的java栈，一个线程的java栈在线程创建的时候被创建，java栈中保存着帧信息，java栈中保存着局部变量、方法参数，同时和java方法的调用、返回密切相关。

6）本地方法栈和java栈非常类似，最大的不同在于java栈用于方法的调用，而本地方法栈则用于本地方法的调用，作为对java虚拟机的重要扩展，java虚拟机允许java直接调用本地方法（通常使用C编写）

7）PC（Program Counter）寄存器也是每一个线程私有的空间，java虚拟机会为每一个java线程创建PC寄存器。在任意时刻，一个java线程总是在执行一个方法，这个正在被执行的方法称为当前方法。如果当前方法不是本地方法，PC寄存器就会指向当前正在被执行的指令。如果当前方法是本地方法，那么PC寄存器的值就是undefined

8)执行引擎是java虚拟机的最核心组件之一，它负责执行虚拟机的字节码，现代虚拟机为了提高执行效率，会使用即时编译技术将方法编译成机器码后再执行。

client:为在客户端环境中减少启动时间而优化。

server:为在服务器环境中最大化程序执行速度而优化。

2、JVM堆结构及分代

         java虚拟机:JVM内存分代策略

         java虚拟机根据对象存活的周期不同，把堆内存划分为几块，一般分为新生代、老年代、永久代(对HotSpot虚拟机而言)，这就是JVM的内存分代策略。

         为什么要分代？

         堆内存是虚拟机管理的内存中最大的一块，也是垃圾回收最频繁的一块区域，我们诚信所有的对象实例都存放堆内存中。给堆内存分代是为了提高对象内存分配和垃圾回收的效率。试想一下如果堆内存没有区域划分，所有的新创建的对象和生命周期很长的对象放在一起，随着程序的执行，堆内存需要频繁进行垃圾收集，而每次回收都要遍历所有对象，遍历这些对象所花费的时间是巨大的，会严重影响我们的GC的效率，这简直太可怕了。

       有了内存分代情况就不同了，新创建的对象会在新生代中分配内存，经过多次回收存活下来的对象存放在老年代中，静态属性、类信息等都会存放在永久代中，新生代中的对象存活时间短，只需要在新生代区域中频繁进行GC，老年代中对象生命周期长，内存回收的频率相对较低，不需要频繁进行回收。永久代中回收效果太差，一般不进行垃圾回收，还可以根据不同年代的特点采用合适的垃圾收集算法。分代收集大大提升了收集效率，这些都是内存分代带来的好处。

      内存分代划分

      java虚拟机将堆内存划分为新生代、老年代、永久代，永久代是Hotspot虚拟机特有的概念，它采用永久代的方法来实现方法区，其他的虚拟机实现没有这一概念，而且Hotspot也有取消永久代的趋势，在jdk1.7中Hotspot已经开始了去永久代，把原本防在永久代的字符串常量池移出。永久代主要存放常量、类信息、静态变量等数据，与垃圾回收关系不大，新生代和老年代是垃圾回收的主要区域。内存分代示意图如下:

或(叫法不同)

在绝大多数情况下，对象首先分配在eden区，在一次新生代回收之后，如果对象还存活，则进入s0或者s1，每经过一次新生代回收，对象如果存活，它的年龄就会加1。当对象的年龄达到一定条件后，就会被认为是老年对象，从而进入老年代。

 

       新生代（Young）

       新生成的对象优先存放在新生代中，新生代对象朝生夕死，存活率很低，在新生代中，常规应用进行一次垃圾收集一般可以回收70% ~ 95% 的空间，回收效率很高。

       HotSpot将新生代划分为三块，一块较大的Eden空间和两块较小的Survivor空间，默认比例为8：1：1。划分的目的是因为HotSpot采用复制算法来回收新生代，设置这个比例是为了充分利用内存空间，减少浪费。新生成的对象在Eden区分配（大对象除外，大对象直接进入老年代），当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。

       GC开始时，对象只会存在于Eden区和From Survivor区，To Survivor区是空的（作为保留区域）。GC进行时，Eden区中所有存活的对象都会被复制到To Survivor区，而在From Survivor区中，仍存活的对象会根据它们的年龄值决定去向，年龄值达到年龄阀值（默认为15，新生代中的对象每熬过一轮垃圾回收，年龄值就加1，GC分代年龄存储在对象的header中）的对象会被移到老年代中，没有达到阀值的对象会被复制到To Survivor区。接着清空Eden区和From Survivor区，新生代中存活的对象都在To Survivor区。接着， From Survivor区和To Survivor区会交换它们的角色，也就是新的To Survivor区就是上次GC清空的From Survivor区，新的From Survivor区就是上次GC的To Survivor区，总之，不管怎样都会保证To Survivor区在一轮GC后是空的。GC时当To Survivor区没有足够的空间存放上一次新生代收集下来的存活对象时，需要依赖老年代进行分配担保，将这些对象存放在老年代中。

       老年代（Old）

       在新生代中经历了多次（具体看虚拟机配置的阀值）GC后仍然存活下来的对象会进入老年代中。老年代中的对象生命周期较长，存活率比较高，在老年代中进行GC的频率相对而言较低，而且回收的速度也比较慢。

       永久代（Permanent）

       永久代存储类信息、常量、静态变量、即时编译器编译后的代码等数据，对这一区域而言，Java虚拟机规范指出可以不进行垃圾收集，一般而言不会进行垃圾回收。

      Minor GC 和 Full GC的区别

       新生代GC（Minor GC）：Minor GC指发生在新生代的GC，因为新生代的Java对象大多都是朝生夕死，所以Minor GC非常频繁，一般回收速度也比较快。当Eden空间不足以为对象分配内存时，会触发Minor GC。

       老年代GC（Full GC/Major GC）：Full GC指发生在老年代的GC，出现了Full GC一般会伴随着至少一次的Minor GC（老年代的对象大部分是Minor GC过程中从新生代进入老年代），比如：分配担保失败。Full GC的速度一般会比Minor GC慢10倍以上。当老年代内存不足或者显式调用System.gc()方法时，会触发Full GC。

       2.1、java栈

       java栈是一块线程私有的内存空间。如果说，java堆和程序数据密切相关，那么java栈就是和线程执行密切相关。线程执行的基本行为是函数调用，每次函数调用的数据都是通过java栈传递的。

       java栈与数据结构上的栈有着类似的含义，它是一块先进后出的数据结构，只支持出栈和进栈两种操作，在java栈中保存的主要内容为栈帧。每一次函数调用，都会有一个对应的栈帧被压入java栈，每一个函数调用结束，都会有一个栈帧被弹出java栈。如下图：栈帧和函数调用。函数1对应栈帧1，函数2对应栈帧2，依次类推。函数1中调用函数2，函数2中调用函数3，函数3调用函数4.当函数1被调用时，栈帧1入栈，当函数2调用时，栈帧2入栈，当函数3被调用时，栈帧3入栈，当函数4被调用时，栈帧4入栈。当前正在执行的函数所对应的帧就是当前帧（位于栈顶），它保存着当前函数的局部变量、中间计算结果等数据。

       当函数返回时，栈帧从java栈中被弹出，java方法区有两种返回函数的方式，一种是正常的函数返回，使用return指令，另一种是抛出异常。不管使用哪种方式，都会导致栈帧被弹出。

       在一个栈帧中，至少包含局部变量表、操作数栈和帧数据区几个部分。

提示：由于每次函数调用都会产生对应的栈帧，从而占用一定的栈空间，因此，如果栈空间不足，那么函数调用自然无法继续进行下去。当请求的栈深度大于最大可用栈深度时，系统会抛出StackOverflowError栈溢出错误。

例2 使用递归，由于递归没有出口，这段代码可能会抛出栈溢出错误，在抛出栈溢出错误时，打印最大的调用深度

　　package com.jvm;

　　public class TestStackDeep {
　　　　private static int count =0;
　　　　public static void recursion(){
　　　　　　count ++;
　　　　　　recursion();
　　　　}

　　　　public static void main(String[] args) {
　　　　　　try{
　　　　　　　　recursion();
　　　　　　}catch(Throwable e){
　　　　　　　　System.out.println("deep of calling ="+count);
　　　　　　　　e.printStackTrace();
　　　　　　}
　　　　}
　　}

使用参数-Xss128K执行上面代码（在eclipse中右键选择Run As-->run Configurations....设置Vm arguments），部分结果如图：

可以看出，在进行大约1079次调用之后，发生了栈溢出错误，通过增大-Xss的值，可以获得更深的层次调用，尝试使用参数-Xss256K执行上述代码，可能产生如下输出，很明显，调用层次有明显的增加：

注意：函数嵌套调用的层次在很大程度上由栈的大小决定，栈越大，函数支持的嵌套调用次数就越多。

       2.1.1、栈帧组成之局部变量表

       局部变量表是栈帧的重要组成部分之一。它用于保存函数的参数以及局部变量，局部变量表中的变量只在当前函数调用中有效，当函数调用结束，随着函数栈帧的弹出销毁，局部变量表也会随之销毁。

       由于局部变量表在栈帧之中，因此，如果函数的参数和局部变量很多，会使得局部变量表膨胀，从而每一次函数调用就会占用更多的栈空间，最终导致函数的嵌套调用次数减少。

       示例3：一个recursion函数含有3个参数和10个局部变量，因此，其局部变量表含有13个变量，而第二个recursion函数不再含有任何参数和局部变量，当这两个函数被嵌套调用时，第二个recursion函数可以拥有更深的调用层次。

package com.jvm;

public class TestStackDeep2 {
　　private static int count = 0;
　　public static void recursion(long a,long b,long c){
　　　　long e=1,f=2,g=3,h=4,i=5,k=6,q=7,x=8,y=9,z=10;
　　　　count ++;
　　　　recursion(a,b,c);
　　}
　　public static void recursion(){
　　　　count++;
　　　　recursion();
　　}

　　public static void main(String[] args) {
　　　　try{
　　　　　　recursion(0L,0L,0L);
　　　　　　//recursion();
　　　　}catch(Throwable e){
　　　　　　System.out.println("deep of calling = "+count);
　　　　　　e.printStackTrace();
　　　　}
　　}
}

使用参数-Xss128K执行上述代码中的第一个带参recursion(long a,long b,long c)函数，输出结果为：

使用虚拟机参数-Xss128K执行上述代码中第二个不带参数的recursion()函数（当然需要把第一个函数注释掉），输出结果为：

可以看出，在相同的栈容量下，局部变量少的函数可以支持更深的函数调用。

使用jclasslib工具可以查看函数的局部变量表，如下图：最大局部变量表大小

该图显示了第一个带参recursion(long a,long b,long c)的最大局部变量表的大小为26个字，因为该函数包含总共13个参数和局部变量，且都为long型，long和double在局部变量表中需要占用2个字，其他如int short byte 对象引用等占用一个字。

说明：字（word）指的是计算机内存中占据一个单独的内存单元编号的一组二进制串，一般32位计算机上一个字为4个字节长度。

通过jclasslib工具查看该类的Class文件中局部变量表的内容，（这里说的局部变量表和上述说的局部变量表不同，这里指Class文件的一个属性，而上述的局部变量表指java栈空间的一部分）

可以看到，在Class文件的局部变量表中，显示了每个局部变量的作用域范围、所在槽位的索引（index列）、变量名（name列）和数据类型（J表示long型）

栈帧中局部变量表中的槽位是可以重用的，如果一个局部变量过了其作用域，那么在其作用域之后申明的新的局部变量就很有可能会复用过期局部变量的槽位，从而达到节省资源的目的。

示例4 ：显示局部变量表的复用，在localvar1函数中，局部变量a和b都作用到了函数的末尾，故b无法复用a所在的位置。而在localvar2()函数中，局部变量a在第？行不再有效，故局部变量b可以复用a的槽位（1个字）

package com.jvm;

public class TestReuse {
　　public static void localvar1(){
　　　　int a=0;
　　　　System.out.println(a);
　　　　int b=0;
　　}
　　public static void localvar2(){
　　　　{
　　　　　　int a=0;
　　　　　　System.out.println(a);
　　　　}
　　　　int b=0;
　　}
}

如图显示localvar1()函数的局部变量表，该函数局部变量大小为2个字，（最大局部变量表中一般第一个局部变量槽位是this引用）第一个槽位是变量a，第二个槽位是变量b，每个变量占一个字。

而localvar2()函数的局部变量表信息如下图，虽然和localvar1()一样，但是b复用了a的槽位，（从他们都占用同一个槽位index都是0可以看出），因此在整个函数执行中，同时存在的局部变量为1字。

局部变量表中的变量也是垃圾回收根节点，只要被局部变量表中直接或者间接引用的对象都是不会被回收的。

示例5：通过一个简单示例，展示局部变量对垃圾回收的影响

package com.jvm;

public class LocalvarGC {
　　public void localvarGc1(){
　　　　byte[] a = new byte[6*1024*1024];//6M
　　　　System.gc();
　　}
　　public void localvarGc2(){
　　　　byte[] a = new byte[6*1024*1024];
　　　　a = null;
　　　　System.gc();
　　}
　　public void localvarGc3(){
　　　　{
　　　　　　byte[] a = new byte[6*1024*1024];
　　　　}
　　　　System.gc();
　　}
　　public void localvarGc4(){
　　　　{
　　　　　　byte[] a = new byte[6*1024*1024];
　　　　}
　　　　int c = 10;
　　　　System.gc();
　　}
　　public void localvarGc5(){
　　　　localvarGc1();
　　　　System.gc();
　　}
　　public static void main(String[] args) {
　　　　LocalvarGC ins = new LocalvarGC();
　　　　ins.localvarGc1();
　　}
}

每一个localvarGcN()函数都分配了一块6M的堆内存，并使用局部变量引用这块空间。

在localvarGc1()中，在申请空间后，立即进行垃圾回收，很明显由于byte数组被变量a引用，因此无法回收这块空间。

在localvarGc2()中，在垃圾回收前，先将变量a置为null，使得byte数组失去强引用，故垃圾回收可以顺利回收byte数组。

在localvarGc3()中，在进行垃圾回收前，先使局部变量a失效，虽然变量a已经离开了作用域，但是变量a依然存在于局部变量表中，并且也指向这块byte数组，故byte数组依然无法被回收。

对于localvarGc4()，在垃圾回收之前，不仅使变量a失效，更是声明了变量c，使变量c复用了变量a的字，由于变量a此时被销毁，故垃圾回收器可以顺利回收数组byte

对于localvarGc5()，它首先调用了localvarGc1()，很明显，在localvarGc1()中并没有释放byte数组，但在localvarGc1()返回后，它的栈帧被销毁，自然也包含了栈帧中的所有局部变量，故byte数组失去了引用，在localvarGc5()的垃圾回收中被回收。

可以使用-XX:+printGC执行上述几个函数，在输出日志里，可以看到垃圾回收前后堆的大小，进而推断出byte数组是否被回收。

下面的输出是函数localvarGc4()的运行结果：

[GC (System.gc()) 7618K->624K(94208K), 0.0015613 secs]
[Full GC (System.gc()) 624K->526K(94208K), 0.0070718 secs]

从日志中可以看出，堆空间从回收前的7618K变为回收后的624K，释放了>6M的空间，byte数组已经被回收释放。

3、JVM垃圾回收算法

       3.1、垃圾回收常见的算法

              a、引用计算法(Reference Counting)

                   比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象，此算法最致命的时无法处理循环引用的问题。

              b、复制(coping)

                   此算法把内存空间划分为两个相等的区域，每次只使用其中一个区域，垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中，此算法每次只处理正在使用中的对象。因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不会出现“碎片”问题，当然，此算法的缺点也是很明显的，就是需要两倍内存空间

       c、标记-清除(Mark-Sweep)

            此算法分为两个阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除，此算法需要暂停整个应用，同时会产生内存碎片。

       d、标记-整理算法(Mark-compact)

  e、分代垃圾收集算法

    分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

    年轻代（Young Generation）的回收算法 (回收主要以Copying为主)

  a) 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。

  b) 新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空， 如此往复。

  c) 当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC(Major GC)，也就是新生代、老年代都进行回收。

  d) 新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。

     年老代（Old Generation）的回收算法（回收主要以Mark-Compact为主）

  a) 在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

  b) 内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。

     持久代（Permanent Generation）的回收算法

  用于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate 等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代也称方法区，具体的回收可参见上文2.5节。

4、JVM垃圾收集器

        a、次收集器

        Scavenge GC（Minor GC），指发生在新生代的GC，因为新生代的Java对象大多都是朝生夕死，所以Scavenge GC非常频繁，一般回收速度也比较快。当Eden空间不足以为对象分配内存时，会触发Scavenge GC。

        一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。

        当年轻代堆空间紧张时会被触发

        相对于全收集而言，收集间隔较短

      b、全收集器

        Full GC，指发生在老年代的GC，出现了Full GC一般会伴随着至少一次的Minor GC（老年代的对象大部分是Scavenge GC过程中从新生代进入老年代），比如：分配担保失败。Full GC的速度一般会比Scavenge GC慢10倍以上。当老年代内存不足或者显式调用System.gc()方法时，会触发Full GC。

        当老年代或者持久代堆空间满了，会触发全收集操作

        可以使用System.gc()方法来显式的启动全收集

        全收集一般根据堆大小的不同，需要的时间不尽相同，但一般会比较长。

 

        Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、版本的虚拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。接下来讨论的收集器基于JDK1.7 Update 14 之后的HotSpot虚拟机（在此版本中正式提供了商用的G1收集器，之前G1仍处于实验状态），该虚拟机包含的所有收集器如下图所示：

        gc-basic
        新生代收集器
        Serial收集器

        Serial（串行）收集器是最基本、发展历史最悠久的收集器，它是采用复制算法的新生代收集器，曾经（JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。它是一个单线程收集器，但“单线程”并非指该收集器只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集时，必须暂停其他所有的工作线程，直至Serial收集器收集结束为止（“Stop The World”）。这项工作是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉，这对很多应用来说是难以接收的。

        下图展示了Serial 收集器（老年代采用Serial Old收集器）的运行过程：

        为了消除或减少工作线程因内存回收而导致的停顿，HotSpot虚拟机开发团队在JDK 1.3之后的Java发展历程中研发出了各种其他的优秀收集器，这些将在稍后介绍。但是这些收集器的诞生并不意味着Serial收集器已经“老而无用”，实际上到现在为止，它依然是HotSpot虚拟机运行在Client模式下的默认的新生代收集器。它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得更高的单线程收集效率。

        在用户的桌面应用场景中，分配给虚拟机管理的内存一般不会很大，收集几十兆甚至一两百兆的新生代（仅仅是新生代使用的内存，桌面应用基本不会再大了），停顿时间完全可以控制在几十毫秒最多一百毫秒以内，只要不频繁发生，这点停顿时间可以接收。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。
ParNew 收集器

        ParNew收集器就是Serial收集器的多线程版本，它也是一个新生代收集器。除了使用多线程进行垃圾收集外，其余行为包括Serial收集器可用的所有控制参数、收集算法（复制算法）、Stop The World、对象分配规则、回收策略等与Serial收集器完全相同，两者共用了相当多的代码。

        ParNew收集器的工作过程如下图（老年代采用Serial Old收集器）：

        ParNew收集器除了使用多线程收集外，其他与Serial收集器相比并无太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关的重要原因是，除了Serial收集器外，目前只有它能和CMS收集器（Concurrent Mark Sweep）配合工作，CMS收集器是JDK 1.5推出的一个具有划时代意义的收集器。

        ParNew 收集器在单CPU的环境中绝对不会有比Serial收集器有更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越。在多CPU环境下，随着CPU的数量增加，它对于GC时系统资源的有效利用是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多的情况下可使用-XX:ParallerGCThreads参数设置。
Parallel Scavenge 收集器

        Parallel Scavenge收集器也是一个并行的多线程新生代收集器，它也使用复制算法。Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标是达到一个可控制的吞吐量（Throughput）。

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

        Parallel Scavenge收集器除了会显而易见地提供可以精确控制吞吐量的参数，还提供了一个参数-XX:+UseAdaptiveSizePolicy，这是一个开关参数，打开参数后，就不需要手工指定新生代的大小-Xmn、Eden和Survivor区的比例-XX:SurvivorRatio、晋升老年代对象年龄-XX:PretenureSizeThreshold等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种方式称为GC自适应的调节策略（GC Ergonomics）。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

        另外值得注意的一点是，Parallel Scavenge收集器无法与CMS收集器配合使用，所以在JDK 1.6推出Parallel Old之前，如果新生代选择Parallel Scavenge收集器，老年代只有Serial Old收集器能与之配合使用。
老年代收集器
Serial Old收集器

        Serial Old 是 Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”（Mark-Compact）算法。

        此收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，它还有两大用途：

    在JDK1.5 以及之前版本（Parallel Old诞生以前）中与Parallel Scavenge收集器搭配使用。
    作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

它的工作流程与Serial收集器相同，这里再次给出Serial/Serial Old配合使用的工作流程图：

Parallel Old收集器

        Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。前面已经提到过，这个收集器是在JDK 1.6中才开始提供的，在此之前，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old以外别无选择，所以在Parallel Old诞生以后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

        Parallel Old收集器的工作流程与Parallel Scavenge相同，这里给出Parallel Scavenge/Parallel Old收集器配合使用的流程图：

CMS收集器

        CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，它非常符合那些集中在互联网站或者B/S系统的服务端上的Java应用，这些应用都非常重视服务的响应速度。从名字上（“Mark Sweep”）就可以看出它是基于“标记-清除”算法实现的。

        CMS收集器工作的整个流程分为以下4个步骤：

    初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The World”。
    并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程，在整个过程中耗时最长。
    重新标记（CMS remark）：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。此阶段也需要“Stop The World”。
    并发清除（CMS concurrent sweep）

        由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作。

        所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。通过下图可以比较清楚地看到CMS收集器的运作步骤中并发和需要停顿的时间：

        优点

        CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿。

        因此CMS收集器也被称为并发低停顿收集器（Concurrent Low Pause Collector）。
        缺点

            对CPU资源非常敏感 其实，面向并发设计的程序都对CPU资源比较敏感。

        在并发阶段，它虽然不会导致用户线程停顿，但会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个时（比如2个），CMS对用户程序的影响就可能变得很大，如果本来CPU负载就比较大，还要分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，其实也让人无法接受。

        无法处理浮动垃圾（Floating Garbage） 可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。

        由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生。这一部分垃圾出现在标记过程之后，CMS无法再当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就被称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。

    标记-清除算法导致的空间碎片 CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。

        空间碎片过多时，将会给大对象分配带来很大麻烦，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象。
        G1收集器

        G1（Garbage-First）收集器是当今收集器技术发展最前沿的成果之一，它是一款面向服务端应用的垃圾收集器，HotSpot开发团队赋予它的使命是（在比较长期的）未来可以替换掉JDK 1.5中发布的CMS收集器。
   特点

    并行与并发 G1 能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短“Stop The World”停顿时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
    分代收集 与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同方式去处理新创建的对象和已存活一段时间、熬过多次GC的旧对象来获取更好的收集效果。
    空间整合 G1从整体来看是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的。这意味着G1运行期间不会产生内存空间碎片，收集后能提供规整的可用内存。此特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
    可预测的停顿 这是G1相对CMS的一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了降低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在GC上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

        横跨整个堆内存

        在G1之前的其他收集器进行收集的范围都是整个新生代或者老生代，而G1不再是这样。G1在使用时，Java堆的内存布局与其他收集器有很大区别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，而都是一部分Region（不需要连续）的集合。
建立可预测的时间模型

        G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。
避免全堆扫描——Remembered Set

        G1把Java堆分为多个Region，就是“化整为零”。但是Region不可能是孤立的，一个对象分配在某个Region中，可以与整个Java堆任意的对象发生引用关系。在做可达性分析确定对象是否存活的时候，需要扫描整个Java堆才能保证准确性，这显然是对GC效率的极大伤害。

        为了避免全堆扫描的发生，虚拟机为G1中每个Region维护了一个与之对应的Remembered Set。虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。
G1收集器的运作步骤

        如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：

    初始标记（Initial Marking） 仅仅只是标记一下GC Roots 能直接关联到的对象，并且修改TAMS（Nest Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以的Region中创建对象，此阶段需要停顿线程，但耗时很短。
    并发标记（Concurrent Marking） 从GC Root 开始对堆中对象进行可达性分析，找到存活对象，此阶段耗时较长，但可与用户程序并发执行。
    最终标记（Final Marking） 为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。
    筛选回收（Live Data Counting and Evacuation） 首先对各个Region中的回收价值和成本进行排序，根据用户所期望的GC 停顿是时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。

通过下图可以比较清楚地看到G1收集器的运作步骤中并发和需要停顿的阶段（Safepoint处）：

总结
收集器     串行/并行/并发     新生代/老年代     算法     目标     适用场景
Serial     串行     新生代     复制算法     响应速度优先     单CPU环境下的Client模式
Serial Old     串行     老年代     标记-整理     响应速度优先     单CPU环境下的Client模式、CMS的后备预案
ParNew     并行     新生代     复制算法     响应速度优先     多CPU环境时在Server模式下与CMS配合
Parallel Scavenge     并行     新生代     复制算法     吞吐量优先     在后台运算而不需要太多交互的任务
Parallel Old     并行     老年代     标记-整理     吞吐量优先     在后台运算而不需要太多交互的任务
CMS     并发     老年代     标记-清除     响应速度优先     集中在互联网站或B/S系统服务端上的Java应用
G1     并发     both     标记-整理+复制算法     响应速度优先     面向服务端应用，将来替换CMS
概念补充
吞吐量（Throughput）

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即

吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）。
原文：https://blog.csdn.net/u013595419/article/details/79332390