JVM运行原理详解

1、JVM 简析：

    作为一名Java 使用者，掌握 JVM 的体系结构是很有必要的。

    说起Java ，我们首先想到的是Java 编程语言，然而事实上，Java 是一种技术，它由四方面组成：Java 编程语言、Java 类文件格式、Java 虚拟机 和 Java 应用程序接口（Java API）。他们的关系图如下：

Java平台

    Java 平台由 Java 虚拟机和 Java 应用程序接口搭建，Java 语言则是进入这个平台的通道，用Java 语言编写并编译程序可以运行在这个平台上。这个平台的结构如下所示：运行期环境代表着Java平台，开发人员编写Java 代码（.java文件），然后将之编译成字节码（.class文件），再然后字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者被即时代码发生器有选择的转换成机器码执行。

Java平台无关性

    JVM 在它的生命周期中有一个明确的任务，那就是运行Java 程序，因此当Java 程序启动的时候，就产生JVM 的一个实例；当程序运行结束的时候，该实例也跟着消失了。在Java 平台的结构中，可以看出，JVM 在核心的位置，是程序与底层操作系统和硬件无关的关键。它的下方是移植接口，移植接口由两部分组成：适配器和Java 操作系统，其中依赖平台的部分称之为适配器；JVM 通过移植接口在具体的平台和操作系统上实现；JVM 的上方是Java 基本类库和扩展类库以及他们的API,利用Java API 编写的应用程序（application）和小程序（Java applet）可以再任何Java 平台上运行而无需考虑底层平台，就是因为有Java 虚拟机（JVM）实现了程序与操作系统的分离，从而实现了Java 的平台无关性。

    下面，我们从JVM 的基本概念和运行过程这两个方面入手，来对它进行深入的研究。

2、JVM 基本概念

（1）基本概念：

    JVM 是可运行Java 程序的假想计算机，包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收、堆和一个存储方法域。JVM 是运行在操作系统之上的，它与硬件没有直接的交互。

（2）运行过程：

    我们都知道Java 源文件，通过编译器，能够产生相应的.class文件，也就是字节码文件，而字节码文件又通过Java 虚拟机的解释器，解释成特定机器上的机器码。

也就是如下：

    ① Java 源文件 ——> 编译器 ——> 字节码文件

    ② 字节码文件 ——> JVM ——> 机器码

    每一种平台的解释器是不同的，但是实现的虚拟机是相同的，这也就是Java 为什么能跨平台的原因了，当一个程序开始运行，这时虚拟机就开始实例化了，多个程序启动就会存在多个虚拟机实例。程序退出或者关闭，则虚拟机实例消亡，多个虚拟机实例之间数据不能共享。

3、JVM 的体系结构

JVM 的体系结构

（1）Class Loader 类加载器

    负责加载.class文件，class文件在文件开头有特定的文件标识，并且ClassLoader 负责class文件的加载。

 类的生命周期：加载 ——> 验证 ——> 准备 ——> 解析 ——> 初始化 ——> 使用 ——> 卸载

 1、加载：

① 通过一个类的全限定名，来获取此类的二进制字节码；

② 将这个字节码所代表的静态存储结构转化为方法区的运行时数据结构；

③ 在Java堆中生成一个代表这个类的Class对象，作为方法区这些数据的访问路口。

2、验证：文件格式验证、元数据验证、字节码验证等。

3、准备：准备阶段是正式为静态变量分配内存并设置静态变量初始值（各数据类型的零值）的阶段，这些内存将在方法区中进行分配。但是如果静态变量的字段属性为常量，则会初始化为指定的值，而不是零值。

4、解析：解析阶段是在虚拟机将符号引用替换为直接引用的过程。直接引用可以是直接指向目标的指针、相对偏移量。

5、初始化：为类的静态变量赋予指定的初始值。

6、使用：使用类之前，必须对类进行实例化，如new或者反射。只有实例化了，才能通过对象的引用来访问对象的实例。

7、卸载：执行垃圾回收。

双亲委派机制：

 JVM的类加载是通过ClassLoader及其子类来完成的，类的层次关系和加载顺序可以由下图来描述：

ClassLoader 类加载机制

自上而下尝试加载，最下面的加载器没有加载到的话，则抛出ClassNotFoundException。

Bootstrap ClassLoader启动类加载器：加载<JAVA_HOME>\lib路径下的jar包，即JDK核心jar包；

Extension ClassLoader扩展类加载器：加载<JAVA_HOME>\lib\ext路径下的jar包；

App ClassLoader应用程序类加载器：加载用户类路径 java -classpath 上所指定的类库。

双亲委派机制的优势：

系统安全性：Java类随着加载它的类加载器一起具备了一种带有优先级的层次关系。比如，Java中的Object类，它存放在rt.jar之中,无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object在各种类加载环境中都是同一个类。如果不采用双亲委派模型，那么由各个类加载器自己去加载的话，那么系统中会存在多种不同的Object类。

（2） Native Interface 本地接口

    本地接口的作用是融合的不同编程语言为Java 所用，它的初衷是融合C/C++ 程序，Java 诞生的时候C/C++ 横行的时候，要想立足，必须调用C/C++ 程序，于是就在内存中专门开辟了一块处理标记为native 的代码，它的具体做法是Native Method Stack 中登记native 方法，在Execution Engine 执行加载native libraries。

（3）Execution Engine 执行引擎

    执行包在类装载的方法中的指令。

（4）Runtime data area 运行数据区

    虚拟机内存，从整个计算机内存中开辟一块内存存储JVM 需要用到的对象、变量等，运行区数据又分为很多小区：方法区，虚拟机栈，本地方法栈，堆，程序计数器。

4、JVM 数据运行区详解（栈管理运行，堆管理存储）

JVM 运行时数据区

    说明：JVM 调优主要就是优化 Heap堆 和 Method Area 方法区，并且这两个区域是线程共享的数据区。

（1）Native Method Stack 本地方法栈

    Native Method Stack 登记native 方法，在Execution Engine 执行加载native libraries。

（2）PC Register 程序计数器

    每个线程都有一个程序计数器，就是一个指针，指向方法区中的方法字节码（下一个将要执行的指令代码），由执行引擎读取下一条指令。

（3）Method Area 方法区

    方法区是被所有线程共享，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap(非堆)，目的是与 Java 堆区分开来。

    对于 HotSpot 虚拟机而言，很多人更愿意把方法区称为"永久带"(Permanent Generation)，本质上两者并不等价，仅仅是因为 HotSpot 虚拟机的设计团队选择把 GC 分代收集扩展至方法区，或者说使用永久代来实现方法区而已。

运行时常量池

    运行时常量池是方法区的一部分，Class 文件中除了有类的版本、字段、方法、接口等描述外，还有一项信息是常量池，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

    采用字面值的方式创建一个字符串时（如 String s1 = "abc"），JVM 首先会去字符串池中查找是否存在 "abc" 这个对象，如果不存在，则在字符串池中创建 "abc" 这个对象，然后将池中 "abc" 这个对象的引用地址返回给 "abc" 对象的引用 s1，这样 s1 会指向池中 "abc" 这个字符串对象；如果存在，则不创建任何对象，直接将池中 "abc" 这个对象的地址返回，赋给引用 s1。

注意：JDK1.8版本中，String 常量池 和 静态变量已经从方法区中的运行时常量池分离到堆中了。

（4）Stack 栈

① 栈是什么

    栈也叫栈内存，主管Java 程序的运行，是在线程创建时创建，它的生命周期跟随线程的生命周期，线程结束栈内存也就释放，对于栈来说，不存在垃圾回收问题，只要线程一结束栈就Over，生命周期和线程一致，是线程私有的。

    基本类型的变量和对象的引用变量都是在栈内存中分配的，但是对象的实例还是保存在堆中的。

② 栈存储什么？

栈帧中主要保存3类数据：

    局部变量（Local Variables）：输入参数和输出参数以及方法类的变量；

    栈操作（Operand Stack）：记录出栈、入栈的操作；

    栈帧数据（Frame Data）：包括类文件、方法等等。

③ 栈运行原理

    栈中的数据都是以栈帧（Stack Frame）的格式存在的，栈帧是一个内存区块。当一个方法被A 调用时就产生了一个栈帧F1，并被压入到栈中，A 方法又调用了B方法，于是产生栈帧F2 也被压入栈，B方法又调用了C 方法，于是产生栈帧F3 也被压入栈，依次执行完毕后，先弹出F3 栈帧，再弹出F2 栈帧，再弹出F1 栈帧。遵循“先进后出”原则。

    当出现递归方法，参数个数过多、递归过深、递归没有出口时，就有可能报 StackOverflow 异常。

（5）Heap 堆

    堆这块区域是JVM 中最大的，实例对象（成员变量，方法）都是存在这个区域，这块区域是GC 主要的回收区，一个 JVM 实例只存在一个堆内存，堆内存大小是可以调节的。类加载器读取了类文件后，需要把类、方法放到堆内存中，以方便执行器执行，堆内存分为三部分：

Heap 堆内存

① 新生代   

    新生代是类的诞生、成长、消亡的区域，一个类在这里产生、应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分：伊甸区（Eden space）和幸存区（Survivor pace），空间分配是 8:1:1，绝大多数的类都是在伊甸区被 new 出来的。幸存区有两个：0区（Survivor 0 space）和 1区（Survivor 1 space）。两个Survivor 区空间一样大，当Eden 区满了，则会触发普通GC，若 Eden 区中的对象经过垃圾回收没有被回收掉，会将Eden 区中的幸存对象移动到幸存区（0或1）。若该幸存区也满了，则继续触发普通 GC，然后将 eden 区和 survivor0 区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，这样在一段时间内，总会有一个空的survivor区。经过多次GC周期后，仍然存活下来的对象会被转移到年老代内存空间 。通常这是在年轻代有资格提升到年老代前通过设定年龄阈值来完成的。需要注意，Survivor的两个区是对称的，没先后关系。

    显然，Survivor 区只是增加了对象在年轻代中逗留的时间，增加了被垃圾回收的可能性。若养老区也满了，那么这时候将产生Full GC，进行养老区的内存清理。若养老区执行Full GC 之后发现依然无法进行对象的保存，就会产生 OOM 异常“OutOfMemoryError”。

    新生代特点：每次垃圾回收时都有大量的对象需要被回收。垃圾回收器在新生代采用的收集算法是Copying(复制)方法：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块面对内存用完了，就将还存活的对象复制到另外一块，然后再把已使用的内存空间一次清理掉。由于新生代有每次垃圾回收时都有大量的对象需要被回收的特点，所以采用Copying算法，复制的存活对象较少，性能比较好。但是Copying算法还是有缺陷的，那就是内存的使用率只有一半。

Copying

    如果出现 java.lang.OutOfMemoryError: Java heap space 异常，说明Java 虚拟机的堆内存不够。可能产生的原因如下：

1、Java 虚拟机的堆内存设置不够，可以通过-Xms、-Xmx来调整；

2、代码中创建了大量大对象，并且长时间不能被垃圾回收器收集；

3、内存加载的数据量太大：一次性从数据库取太多数据；

4、集合类中有对对象的引用，使用后未清空，GC不能进行回收；

5、代码中存在循环产生过多的重复对象。

② 老年区

年轻代中经过垃圾回收没有回收掉的对象将被Copy到年老代。

老年代的特点： 每次垃圾回收时只有少量的对象需要被回收。垃圾回收器在老年代采用的收集算法是 Mark-Compact 算法：为了解决 Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。它先将需要回收的对象进行标记，然后将存活对象都向一端移动，然后清理掉端边界以外的内存。

Mark-Compact

③ 永久代

    只有 HotSpot 虚拟机才有永久代的概念，永久代存放类的常量、静态变量等信息，是方法区的实现，可以直接理解为方法区，所以实际上，永久代不属于堆，而是方法区。对永久代的回收主要回收两部分内容：废弃常量和无用的类。

    如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java 虚拟机对永久带Perm内存设置不够。原因有二：

1、程序启动需要加载大量的第三方jar包。例如：在一个Tomcat 下部署了太多的应用。

2、大量动态反射生成的类不断被加载，最终导致Perm 区被占满。

注意：JDK1.8 之后，不存在永久代，即没有 java.lang.OutOfMemoryError: PermGen space 这种错误。取而代之的是 Meta space（元空间）。之前存储在永久带的字符串常量，静态变量移到了堆中去了，元空间不存储在虚拟机中，而是存储在本地内存中。元空间存储的是 class 文件在 jvm 里的运行时数据结构，如 method，constantPool（运行时常量池）。

JDK 1.8之前堆内存结构图 JDK 1.8堆内存结构图

4、垃圾回收机制

垃圾回收：当一个对象没有引用指向它时，这个对象就成为无用的内存（垃圾），就必须进行回收，以便于后续其他对象的内存分配。

判断对象是否存活的方法——可达性分析：程序把所有的引用关系看做一张图，如果一个节点与GC Roots之间没有引用链存在，则该节点视为垃圾回收的对象。

可作为GC Roots对象的包括如下几种：

1、虚拟机栈（栈帧中的本地变量表）中引用的对象；

2、方法区中的静态变量引用的对象；

3、方法区中常量引用的对象；

4、本地方法栈中JNI(Java Native Interface)引用的对象。

5、内存调优简介

在说内存调优之前，我们先了解下内存泄漏和内存溢出。

内存泄漏：是指程序申请内存后，无法释放已申请的内存空间，一次内存泄漏似乎不会影响很大的影响，但是内存泄漏堆积后的后果就是内存溢出。

内存溢出：指程序申请内存时，没有足够的内存供申请者使用。

内存溢出的几种原因：

1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据； 

2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收； 

3.代码中存在死循环或循环产生过多重复的对象实体； 

4.使用的第三方软件中的BUG； 

5.启动参数内存值设定的过小（-Xms、-Xmx）。

调优参数：

内存调优参数 JDK 1.8内存容量查询

    说明：在Run Config中的 vm options 中输入“-XX:+PrintGCDtails”，可以看到堆内存运行情况：

JDK1.8 内存运行情况（示例）

（1） 堆大小设置

典型设置：

1、java -Xmx3550m -Xms3550m -Xmn2g -Xss128k

    -Xmx3550m：设置JVM 最大可用内存为3550M。

    -Xms3550m：设置JVM 初始内存为3550m。此值可以设置与-Xmx 相同，以避免每次垃圾回收完成后JVM 重新分配内存。

    -Xmn2g：设置新生代大小为2G。整个JVM内存大小 = 新生代大小 + 老年代大小  + 元空间。Sun 官方推荐配置为整个堆内存的3/8。

    -Xss256K：每个线程默认会开启1M的堆栈，用于存放栈帧、调用参数、局部变量等，对大多数应用而言这个默认值太了，一般256K就足用。理论上，在内存不变的情况下，减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统。

2、java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4  -XX:MaxTenuringThreshold=3

    -XX:NewRatio = 4：设置新生代（包括Eden和两个Survivor 区）与老年代（出去元空间）的比值。设置为4，则新生代与老年代所占比值为1:4，新生代占整个堆内存的1/5。

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

    -XX:MaxTenuringThreshold=3：设置垃圾最大年龄为3，即对象在Survivor 区存在的年龄为3（复制一次年龄+1）。如果设置为0，则年轻代对象不经过Survivor 区，直接进入老年代。对于老年代比较多的应用，可以提高效率。如果将此设置为一个较大的值，则年轻代对象会在Survivor 区进行多次复制，这样可以增加对象在年轻代存活的时间，增加在年轻代被回收的概率。此参数只有在串行GC时才有效。

（2）回收器选择

    JVM 给了三种选择：串行收集器（单线程）、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应的参数。JDK5.0以后，JVM会根据当前系统配置进行判断。

    并行算法是用多线程进行垃圾回收，回收期间会暂停程序的执行，而并发算法，也是多线程回收，但期间不停止应用执行。所以，并发算法适用于交互性高的一些程序。经过观察，并发算法会减少年轻代的大小，其实就是使用了一个大的年老代，这反过来跟并行算法相比吞吐量相对较低。

1、吞吐量优先的并行收集器

    并行收集器主要以达到一定吞吐量为目标，适用于后台处理等。

典型配置：

java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 

    -XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。

    -XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC

-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100

-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy

-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。

2、响应时间优先的并发收集器

    并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。

典型配置：

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。

-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection

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

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

（3）调优总结

1、年轻代大小选择

响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。

吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

2、年老代大小选择

① 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：

   1、并发垃圾收集信息

   2、持久代并发收集次数

   3、传统GC信息

   4、花在年轻代和年老代回收上的时间比例

减少年轻代和年老代花费的时间，一般会提高应用的效率

② 吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。

3、较小堆引起的碎片问题

    因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：

1、-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。

2、-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩。

4、调优策略

    调优的目标：

    1、GC的时间足够小；

    2、GC的次数足够小；

    3、发送Full GC的周期足够长。

    前两个目前是相悖的，要想GC 时间小必须要一个更小的堆；要保证GC 次数足够小，必须保证一个更大的堆，我们只能取其平衡。

    （1）针对JVM堆的设置一般，可以通过-Xms，-Xmx限定其最小、最大值，为了防止垃圾收集器在最小、最大之间收缩堆而产生额外的时间，我们通常把最大、最小设置为相同的值。

    （2）年轻代和年老代将根据默认的比例（1：2）分配堆内存，可以通过调整二者之间的比率NewRadio来调整二者之间的大小，也可以针对回收代，比如年轻代，通过 -XX:newSize（设置年轻代大小），-XX:MaxNewSize（设置年轻代最大值）来设置其绝对大小。同样，为了防止年轻代的堆收缩，我们通常会把-XX:newSize -XX:MaxNewSize设置为同样大小。

   （3）年轻代和年老代设置多大才算合理？这个我问题毫无疑问是没有答案的，否则也就不会有调优。我们观察一下二者大小变化有哪些影响。

        1、更大的年轻代必然导致更小的年老代，大的年轻代会延长普通GC的周期，但会增加每次GC的时间；小的年老代会导致更频繁的Full GC。

        2、更小的年轻代必然导致更大年老代，小的年轻代会导致普通GC很频繁，但每次GC 的时间会更短；大的年老代会减少Full GC的频率。

    （4）在配置较好的机器上（比如多核、大内存），可以为年老代选择并行收集算法：-XX:+UseParallelOldGC，默认Serial收集。

    （5）可以通过下面的参数打印 Heap Dump 信息：

        -XX:HeapDumpPath

        -XX:+PrintGCDetails

        -XX:+PrintGCTimeStamps

        -Xloggc:/usr/aaa/dump/heap_trace.txt

    通过下面参数可以控制OutOfMemoryError时打印堆的信息：

        -XX:+HeapDumpOnOutOfMemoryError

    提供一个的Java参数配置示例：（服务器：Linux 64Bit，8Core×16G）

    JAVA_OPTS="$JAVA_OPTS -server -Xms3G -Xmx3G -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/aaa/dump -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/usr/aaa/dump/heap_trace.txt -XX:NewSize=1G -XX:MaxNewSize=1G"