JAVA虚拟机

什么是Java虚拟机

Java虚拟机（JVM）是运行 Java 字节码的虚拟机。JVM有针对不同系统的特定实现（Windows，Linux，macOS），目的是使用相同的字节码，它们都会给出相同的结果。字节码和不同系统的 JVM 实现是 Java 语言“一次编译，随处可以运行”的关键所在。

Java变量的分类

java变量大致可以分为三类，第一类为局部变量；第二类为成员变量（通常也称为实例变量）；第三类为静态变量。

第一类：局部变量（local variable）
局部变量是方法或语句块内部定义的变量，其生命周期是从声明位置开始到方法或语句块执行完毕为止。局部变量在使用前必须先声明并初始化（赋值），否则会出错。
局部变量的初始化有两种方式，一种是先定义再初始化，代码中方式一所示，另外一种是定义的同时进行初始化，如方式二所示。

第二类：成员变量（member variable）
在某个方法外部，类内部定义的变量，从属于对象，生命周期伴随对象始终。如果不自行初始化，它会自动初始化成该类型默认的初始值。部分变量的默认初始值如下表所示

## 第三类：静态变量（static variable）
静态变量使用static定义，从属于类，生命周期伴随类始终，从类加载时产生，类卸载时结束。如果不进行初始化，与成员变量一样，会自行初始化成该类型的默认初始值。

成员变量（又称实例变量，在实例里面）是在一个对象内部创建的
静态变量（又称类变量）是在类内部创建的

JVM各种变量存储位置

静态变量 位于方法区
实例变量 作为对象的一部分，保存在堆中。
临时（局部）变量 保存于栈中，栈随线程的创建而被分配。

new和malloc申请的在堆区,函数局部变量和函数参数在栈区,全局和静态变量在全局区(静态区)

jvm的内存结构

1.栈是存储局部变量的，也是线程独有的区域，也就是每一个线程都会有自己独立的栈区域。

2. 程序计数器
jvm虚拟机为什么要设置程序计数器这个结构呢？就是为了多线程的出现，多线程之间的切换，当一个程序被挂起的时候，总是要恢复的，那么恢复到哪个位置呢，总不能又重新开始执行吧，那么程序计数器就解决了这个问题。

3.方法区（Method Area）与 Java 堆一样，是所有线程共享的内存区域。

类加载其实最终是以类元信息的形式存储在方法区中的

用于存储已被虚拟机加载的类信息、常量、静态变量，如static修饰的变量加载类的时候就被加载到方法区中。

4.堆

堆是最重要的一块内存区域

对于这个基本组成大家应该都有所了解，堆就是由年轻代和老年代组成，年轻代又分为伊甸园区和survivor区，survivor区中又有from区和to区.

new出来的对象一般都放在Eden区

假设我们给对分配600M内存，这个是可以通过参数调节的，我们后文再讲。那么老年代默认是占2/3的，也就是差不多400M，那年轻代就是200M，Eden区160M，Survivor区40M。

简述分代垃圾回收器是怎么工作的

堆就是由年轻代和老年代组成，年轻代又分为伊甸园区和survivor区，survivor区中又有from区和to区.

new出来的对象一般都放在Eden区

Eden + From Survivor 存活的对象放入 To Survivor 区；

清空 Eden 和 From Survivor 分区； From Survivor 和 To Survivor 分区交换，From Survivor 变 To Survivor，To Survivor 变 From Survivor。

每次在 From Survivor 到 To Survivor 移动时都存活的对象，年龄就 +1，当年龄到达 15（默认配置是 15）时，升级为老生代。大对象也会直接进入老生代。

老生代当空间占用到达某个值之后就会触发全局垃圾收回，一般使用标记整理的执行算法。

以上这些循环往复就构成了整个分代垃圾回收的整体执行流程。

gc

这里的gc属于minor gc，就是垃圾收集，来收集垃圾对象并清理的

这里就涉及到了一个GC Root根以及可达性分析算法的概念，也是面试偶尔会被问到的。

根搜索算法：也就是将对象关系以图关系进行搜索，如果一个对象度为0或者没有与GCroot相连说明改对象不可用。目前Java使用这种方法。

可达性分析算法是将GC Roots对象作为起点，从这些起点开始向下搜索引用的对象，找到的对象都标记为非垃圾对象，其余未标记的都是垃圾对象

那么GC Roots根对象又是什么呢，GC Roots根就是判断一个对象是否可以回收的依据，只要能通过GC Roots根向下一直搜索能搜索到的对象，那么这个对象就不算垃圾对象，而可以作为GC Roots根的有线程栈的本地变量，静态变量，本地方法栈的变量等等，说白了就是找到和根节点有联系的对象就是有用的对象，其余都认为是垃圾对象来回收。

复制算法
经历了第一次minor gc后，没有被清理的对象就会被移到From区，如上图。

一个对象每经历一次gc，那么它的gc分代年龄就会+1，如上图。

那么如果第二次新的对象又把Eden区放满了，那么又会执行minor gc，但是这次会连着From区一起gc，然后将Eden区和From区存活的对象都移到To区域，对象头中分代年龄都+1，如上图。

那么当第三次Eden区又满的时候，minor gc就是回收Eden区和To区域了，TEden区和To区域还活着的对象就会都移到From区，如上图。说白了就是Survivor区中总有一块区域是空着的，存活的对象存放是在From区和To区轮流存放，也就是互相复制拷贝，这也就是垃圾回收算法中的复制-回收算法。如果一个对象经历了一个限值15次gc的时候，就会移至老年代。那如果还没有到限值，From区或者To区域也放不下了，就会直接挪到老年代，这只是举例了两种常规规则，还有其他规则也是会把对象存放至老年代的。那么随着应用程序的不断运行，老年代最终也是会满的，那么此时也会gc，此时的gc就是Full gc了。

标记清除算法

当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。

缺点：此算法需要暂停整个应用，会产生内存碎片
通俗的话解释一下标记/清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将依旧存活的对象标记一遍，最终再将堆中所有没被标记的对象全部清除掉，接下来便让程序恢复运行。

劣势1、首先，它的缺点就是效率比较低（递归与全堆对象遍历），而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲2、其次，主要的缺点则是这种方式清理出来的空闲内存是不连续的，而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

垃圾回收在jvm中优先级相当相当低。
垃圾收集器（GC）程序开发者只能推荐JVM进行回收，但何时回收，回收哪些，程序员不能控制。
垃圾回收机制只是回收不再使用的JVM内存，如果程序有严重BUG，照样内存溢出。
进入DEAD的线程，它还可以恢复，GC不会回收

GC 调优策略

将转移到老年代的对象数量降低到最小； 减少 GC 的执行时间。

策略 1：将新对象预留在新生代，由于 Full GC 的成本远高于 Minor GC，因此尽可能将对象分配在新生代是明智的做法，实际项目中根据 GC 日志分析新生代空间大小分配是否合理，适当通过“-Xmn”命令调节新生代大小，最大限度降低新对象直接进入老年代的情况。

策略 2：大对象进入老年代，虽然大部分情况下，将对象分配在新生代是合理的。但是对于大对象这种做法却值得商榷，大对象如果首次在新生代分配可能会出现空间不足导致很多年龄不够的小对象被分配的老年代，破坏新生代的对象结构，可能会出现频繁的 full gc。因此，对于大对象，可以设置直接进入老年代（当然短命的大对象对于垃圾回收来说简直就是噩梦）。-XX:PretenureSizeThreshold 可以设置直接进入老年代的对象大小。

策略 3：合理设置进入老年代对象的年龄，-XX:MaxTenuringThreshold 设置对象进入老年代的年龄大小，减少老年代的内存占用，降低 full gc 发生的频率。

策略 4：设置稳定的堆大小，堆大小设置有两个参数：-Xms 初始化堆大小，-Xmx 最大堆大小。

为什么要分为Eden和Survivor?为什么要设置两个Survivor区？

如果没有Survivor，Eden区每进行一次Minor GC，存活的对象就会被送到老年代。老年代很快被填满，触发Full GC.老年代的内存空间远大于新生代，进行一次Full GC消耗的时间比Minor GC长得多,所以需要分为Eden和Survivor。
Survivor的存在意义，就是减少被送到老年代的对象，进而减少Full GC的发生，Survivor的预筛选保证，只有经历16次Minor GC还能在新生代中存活的对象，才会被送到老年代。
设置两个Survivor区最大的好处就是解决了碎片化，刚刚新建的对象在Eden中，经历一次Minor GC，Eden中的存活对象就会被移动到第一块survivor space S0，Eden被清空；等Eden区再满了，就再触发一次Minor GC，Eden和S0中的存活对象又会被复制送入第二块survivor space S1（这个过程非常重要，因为这种复制算法保证了S1中来自S0和Eden两部分的存活对象占用连续的内存空间，避免了碎片化的发生）

Major GC 发生在老年代的GC，清理老年区，经常会伴随至少一次Minor GC，比Minor GC慢10倍以上。

Stop-the-world（任何GC算法中都会发生）

它是指 JVM 由于要执行 GC 而停止了应用程序的执行，并且这种情形会在任何一种 GC 算法中发生。当 Stop-the-world 发生时，除了 GC 的线程以外，其他的线程均处于等待的状态，直到 GC 任务完成。

实际上，很多 GC 优化都是通过减少 Stop-the-world 的时间来提高程序的性能。

你知道哪几种垃圾收集器，各自的优缺点，重点讲下cms和G1，包括原理，流程，优缺点。

思路： 一定要记住典型的垃圾收集器，尤其cms和G1，它们的原理与区别，涉及的垃圾回收算法。

我的答案：

1）几种垃圾收集器：

Serial收集器： 单线程的收集器，收集垃圾时，必须stop the world，使用复制算法。
ParNew收集器： Serial收集器的多线程版本，也需要stop the world，复制算法。
Parallel Scavenge收集器： 新生代收集器，复制算法的收集器，并发的多线程收集器，目标是达到一个可控的吞吐量。如果虚拟机总共运行100分钟，其中垃圾花掉1分钟，吞吐量就是99%。
Serial Old收集器： 是Serial收集器的老年代版本，单线程收集器，使用标记整理算法。
Parallel Old收集器： 是Parallel Scavenge收集器的老年代版本，使用多线程，标记-整理算法。

CMS(Concurrent Mark Sweep) 收集器： 是一种以获得最短回收停顿时间为目标的收集器，标记清除算法，运作过程：初始标记，并发标记，重新标记，并发清除，收集结束会产生大量空间碎片。

G1收集器： 标记整理算法实现，运作流程主要包括以下：初始标记，并发标记，最终标记，筛选标记。不会产生空间碎片，可以精确地控制停顿。

CMS收集器和G1收集器的区别：

CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用；
G1收集器收集范围是老年代和新生代，不需要结合其他收集器使用；
CMS收集器以最小的停顿时间为目标的收集器；
G1收集器可预测垃圾回收的停顿时间
CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片
G1收集器使用的是“标记-整理”算法，进行了空间整合，降低了内存空间碎片。

jvm内存溢出的种类

1.栈溢出

首先搞清楚java栈空间存储的是什么。java栈空间是线程私有的，是java方法执行的内存模型。每个方法执行时都会在java栈空间产生一个栈帧，存放方法的变量表，返回值等信息，方法的执行到结束就是一个栈帧入栈到出栈的过程。

所以栈溢出的原因一般是循环调用方法导致栈帧不断增多，栈深度不断增加，最终没有内存可以分配，出现StackOverflowError，比如下面这种情况：

public class stack{

public void test(){

    this.test();
}
public static void main(String[] args){
    for(; ; ;)
        new stack().test;
}

}
栈内存溢出一般是程序错误导致，如递归死循环等等。

如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常，方法递归调用产生这种结果。
如果Java虚拟机栈可以动态扩展，并且扩展的动作已经尝试过，但是无法申请到足够的内存去完成扩展，或者在新建立线程的时候没有足够的内存去创建对应的虚拟机栈，那么Java虚拟机将抛出一个OutOfMemory 异常。(线程启动过多)

2.堆溢出

持久代溢出
无法创建
本地线程

内存泄露 memory leak，

是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。

为什么会产生内存泄漏？
当一个对象已经不需要再使用本该被回收时，另外一个正在使用的对象持有它的引用从而导致它不能被回收，这导致本该被回收的对象不能被回收而停留在堆内存中，这就产生了内存泄漏。

对象创建，引用对象的类型

在java语言中，除了原始数据类型（boolean、byte、short、char、int、float、double、long）的变量，其他所有都是所谓的引用类型，指向各种不同的对象。

1.强引用（strong reference）
强引用就是我们最常见的普通对象引用（如new 一个对象），只要还有强引用指向一个对象，就表明此对象还“活着”。在强引用面前，即使JVM内存空间不足，JVM宁愿抛出OutOfMemoryError运行时错误（OOM），让程序异常终止，也不会靠回收强引用对象来解决内存不足的问题。对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显式地将相应（强）引用赋值为null，就意味着此对象可以被垃圾收集了。但要注意的是，并不是赋值为null后就立马被垃圾回收，具体的回收时机还是要看垃圾收集策略的。
如Object obj = new Object();

2.软引用（soft reference）
软引用相对强引用要弱化一些，可以让对象豁免一些垃圾收集。当内存空间足够的时候，垃圾回收器不会回收它。只有当JVM认定内存空间不足时才会去回收软引用指向的对象。JVM会确保在抛出OOM前清理软引用指向的对象，而且JVM是很聪明的，会尽可能优先回收长时间闲置不用的软引用指向的对象，对那些刚构建的或刚使用过的软引用指向的对象尽可能的保留。基于软引用的这些特性，软引用可以用来实现很多内存敏感点的缓存场景，即如果内存还有空闲，可以暂时缓存一些业务场景所需的数据，当内存不足时就可以清理掉，等后面再需要时，可以重新获取并再次缓存。这样就确保在使用缓存提升性能的同时，不会导致耗尽内存。
软引用通常可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，java虚拟机就会把这个软引用加入到与之关联的引用队列中。

Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);
obj = null;
//有时候会返回null
sf.get();　

SoftReference<List<Foo>> ref = new SoftReference<List<Foo>>(new LinkedList<Foo>());
  
// somewhere else in your code, you create a Foo that you want to add to the list
List<Foo> list = ref.get();
if (list != null)
{
    list.add(foo);
}
else
{
    // list is gone; do whatever is appropriate
}　

在使用软引用的时候必须检查引用是否为null。因为垃圾收集器可能在任意时刻回收软引用，如果不做是否null的判断，可能会出现NullPointerException的异常。
总的来说，软引用是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常

类的加载过程

类装载分为以下 5 个步骤：
加载：根据查找路径找到相应的 class 文件然后导入；
验证：检查加载的 class 文件的正确性；
准备：给类中的静态变量分配内存空间；
解析：虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标示，而在直接引用直接指向内存中的地址；
初始化：对静态变量和静态代码块执行初始化工作。

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。其中验证、准备、解析3个部分统称为连接（Linking），

1.加载
在加载阶段，虚拟机需要完成以下3件事情：

1）通过一个类的全限

定名来获取定义此类的二进制字节流。

2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3）在内存（即方法区）中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
2、验证
验证是链接阶段的第一步，这一步主要的目的是确保class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身安全。

3、准备
准备阶段是正式为类变量分配内存并设置类变量默认值的阶段，这些内存都将在方法区中进行分配。

4、解析
解析阶段是虚拟机常量池内的符号引用替换为直接引用的过程。
符号引用：符号引用是一组符号来描述所引用的目标对象，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标对象并不一定已经加载到内存中。
直接引用：直接引用可以是直接指向目标对象的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机内存布局实现相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同，如果有了直接引用，那引用的目标必定已经在内存中存在。

5.初始化

类的初始化的主要工作是为静态变量赋程序设定的初值。

初始化是为类的静态变量赋予正确的初始值，准备阶段和初始化阶段看似有点矛盾，其实是不矛盾的，如果类中有语句：private static int a = 10，它的执行过程是这样的，首先字节码文件被加载到内存后，先进行链接的验证这一步骤，验证通过后准备阶段，给a分配内存，因为变量a是static的，所以此时a等于int类型的默认初始值0，即a=0,然后到解析（后面在说），到初始化这一步骤时，才把a的真正的值10赋给a,此时a=10。

什么时候对类进行初始化

对于初始化阶段的时机，虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始：

**1）**遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

**2）**使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。

**3）**当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

**4）**当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。

类加载器

类加载器 就是根据指定全限定名称将class文件加载到JVM内存，转为Class对象

类加载器负责加载所有的类，其为所有被载入内存中的类生成一个java.lang.Class实例对象。一旦一个类被加载如JVM中，同一个类就不会被再次载入了。正如一个对象有一个唯一的标识一样，一个载入JVM的类也有一个唯一的标识。在Java中，一个类用其全限定类名（包括包名和类名）作为标识；但在JVM中，一个类用其全限定类名和其类加载器作为其唯一标识。例如，如果在pg的包中有一个名为Person的类，被类加载器ClassLoader的实例kl负责加载，则该Person类对应的Class对象在JVM中表示为(Person.pg.kl)。这意味着两个类加载器加载的同名类：（Person.pg.kl）和（Person.pg.kl2）是不同的、它们所加载的类也是完全不同、互不兼容的。
1)根类加载器（bootstrap class loader）:它用来加载 Java 的核心类，是用原生代码来实现的，并不继承自 java.lang.ClassLoader（负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
2)扩展类加载器（extensions class loader）：它负责加载JRE的扩展目录，lib/ext或者由java.ext.dirs系统属性指定的目录中的JAR包的类。由Java语言实现，父类加载器为null。

3)系统类加载器（system class loader）：被称为系统（也称为应用）类加载器，它负责在JVM启动时加载来自Java命令的-classpath选项、java.class.path系统属性，或者CLASSPATH换将变量所指定的JAR包和类路径。程序可以通过ClassLoader的静态方法getSystemClassLoader()来获取系统类加载器。如果没有特别指定，则用户自定义的类加载器都以此类加载器作为父加载器。由Java语言实现，父类加载器为ExtClassLoader。

类加载器加载Class大致要经过如下8个步骤：

1. 检测此Class是否载入过，即在缓冲区中是否有此Class，如果有直接进入第8步，否则进入第2步。
2. 如果没有父类加载器，则要么Parent是根类加载器，要么本身就是根类加载器，则跳到第4步，如果父类加载器存在，则进入第3步。
3. 请求使用父类加载器去载入目标类，如果载入成功则跳至第8步，否则接着执行第5步。
4. 请求使用根类加载器去载入目标类，如果载入成功则跳至第8步，否则跳至第7步。
5. 当前类加载器尝试寻找Class文件，如果找到则执行第6步，如果找不到则执行第7步。
6. 从文件中载入Class，成功后跳至第8步。
7. 抛出ClassNotFountException异常。
8. 返回对应的java.lang.Class对象。

1) 什么是类加载器？

类加载器 就是根据指定全限定名称将class文件加载到JVM内存，转为Class对象。

启动类加载器（Bootstrap ClassLoader）：由C++语言实现（针对HotSpot）,负责将存放在<JAVA_HOME>\lib目录或-Xbootclasspath参数指定的路径中的类库加载到内存中。

用来加载java的核心类库
jre lib下的架包
resources
加载拓展类和应用程序类加载器，并指定为他们的父类加载器

其他类加载器：由Java语言实现，继承自抽象类ClassLoader。如：
扩展类加载器（Extension ClassLoader）：负责加载<JAVA_HOME>\lib\ext目录或java.ext.dirs系统变量指定的路径中的所有类库。
父类加载器为启动类加载器
如果用户创建的JAR包放在此目录下，也会被扩展类加载器加载

应用程序类加载器（Application ClassLoader）。负责加载用户类路径（classpath）上的指定类库，我们可以直接使用这个类加载器。一般情况，如果我们没有自定义类加载器默认就是用这个加载器。

为什么要自定义类加载器

隔离加载类：不同的中间件里的类可能路径名字都相同，这样可以避免冲突
可以进行动态加载

2）双亲委派模型

双亲委派模型工作过程是：

如果一个类加载器收到类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器完成。每个类加载器都是如此，只有当父加载器在自己的搜索范围内找不到指定的类时（即ClassNotFoundException），子加载器才会尝试自己去加载。

双亲委派模型图：

3）为什么需要双亲委派模型？

在这里，先想一下，如果没有双亲委派，那么用户是不是可以自己定义一个java.lang.Object的同名类，java.lang.String的同名类，并把它放到ClassPath中,那么类之间的比较结果及类的唯一性将无法保证，因此，为什么需要双亲委派模型？防止内存中出现多份同样的字节码

并且这样比较安全

4）怎么打破双亲委派模型？

打破双亲委派机制则不仅要继承ClassLoader类，还要重写loadClass和findClass方法

说说你知道的几种主要的JVM参数

思路： 可以说一下堆栈配置相关的，垃圾收集器相关的，还有一下辅助信息相关的。

我的答案：

1）堆栈配置相关

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-XX:MaxPermSize=16m -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxTenuringThreshold=0
-Xmx3550m： 最大堆大小为3550m。

-Xms3550m： 设置初始堆大小为3550m。

-Xmn2g： 设置年轻代大小为2g。

-Xss128k： 每个线程的堆栈大小为128k。

-XX:MaxPermSize： 设置持久代大小为16m

-XX:NewRatio=4: 设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。

-XX:SurvivorRatio=4： 设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6

-XX:MaxTenuringThreshold=0： 设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。

2）垃圾收集器相关

-XX:+UseParallelGC
-XX:ParallelGCThreads=20
-XX:+UseConcMarkSweepGC
-XX:CMSFullGCsBeforeCompaction=5
-XX:+UseCMSCompactAtFullCollection：
-XX:+UseParallelGC： 选择垃圾收集器为并行收集器。

-XX:ParallelGCThreads=20： 配置并行收集器的线程数

-XX:+UseConcMarkSweepGC： 设置年老代为并发收集。

-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。

-XX:+UseCMSCompactAtFullCollection： 打开对年老代的压缩。可能会影响性能，但是可以消除碎片

3）辅助信息相关

-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGC 输出形式:

[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]

-XX:+PrintGCDetails 输出形式:

[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs