JVM参数相关理解

JVM内存模型可以分为两个部分，如下图所示，堆和方法区是所有线程共有的，而虚拟机栈，本地方法栈和程序计数器则是线程私有的。

堆（Heap）

在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )，新生代 ( Young ) 又被划分为三个区域：Eden、From Survivor、To Survivor。

下图中的Perm代表的是永久代，但是注意永久代并不属于堆内存中的一部分，同时jdk1.8之后永久代也将被移除。

堆是java虚拟机所管理的内存中最大的一块内存区域，也是被各个线程共享的内存区域，该内存区域存放了对象实例及数组（但不是所有的对象实例都在堆中）。

其大小通过-Xms(最小值)和-Xmx(最大值)参数设置（最大最小值都要小于1G），前者为启动时申请的最小内存，默认为操作系统物理内存的1/64，后者为JVM可申请的最大内存,默认为物理内存的1/4，默认当空余堆内存小于40%时，JVM会增大堆内存到-Xmx指定的大小，可通过-XX:MinHeapFreeRation=来指定这个比列。

当空余堆内存大于70%时，JVM会减小堆内存的大小到-Xms指定的大小，可通过XX:MaxHeapFreeRation=来指定这个比列，当然为了避免在运行时频繁调整Heap的大小，通常-Xms与-Xmx的值设成一样。堆内存 = 新生代+老生代+持久代。

在我们垃圾回收的时候，我们往往将堆内存分成新生代和老生代（大小比例1：2），新生代中由Eden和Survivor0，Survivor1组成，三者的比例是8：1：1，新生代的回收机制采用复制算法，在Minor GC的时候，我们都留一个存活区用来存放存活的对象，真正进行的区域是Eden+其中一个存活区，当我们的对象时长超过一定年龄时（默认15，可以通过参数设置），将会把对象放入老生代，当然大的对象会直接进入老生代，老生代采用的回收算法是标记整理算法。

方法区（Method Area）

其实方法区是在JDK1.8以前的版本里存在的一块内存区域，主要就是存放从class文件里加载进来的类的，而且常量池也是在这块区域内的。

但是在JDK1.8之后，这块区域摇身一变，换了名字，叫做“Metaspace”，翻译过来就是“元数据空间”的意思，当然它只是改了个名，实现的功能是没变的。

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

1.类型信息

对每个加载的类型（类class、接口interface、枚举enum、注解annotation),JVM必须在方法区中存储以下类型信息:
①这个类型的完整有效名称（全名=包名.类名)
②这个类型直接父类的完整有效名(对于interface或是java.lang.0bject，都没有父类)
③这个类型的修饰符(public, abstract,final的某个子集)
④这个类型直接接口的一个有序列表

2.域信息(Field)成员变量

JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
域的相关信息包括:域名称、域类型、域修饰符(public, private,protected,static,final, volatile, transient的某个子集)

3.方法(Method)信息

JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序:

• 方法名称
• 方法的返回类型(或void)·方法参数的数量和类型(按顺序)
• 方法的修饰符(public, private,protected,static, final,synchronized,native,abstract的一个子集)
• 方法的字节码(bytecodes)、操作数栈、局部变量表及大小(abstract和native方法除外)

虚拟机栈(JVM Stack)

虚拟机栈（Java Virtual Machine Stack），早期也叫Java栈，每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应着一次次的Java方法调用。

虚拟机栈的作用：主管Java程序的运行，它保存方法的局部变量、部分结果，并参与方法的调用和返回。

每个方法被执行的时候都会创建一个”栈帧”,用于存储局部变量表(包括参数)、操作栈、方法出口等信息。

每个方法被调用到执行完的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

栈帧（Stack Frame） 是用于虚拟机执行时方法调用和方法执行时的数据结构，它是虚拟栈的基本元素，栈帧由局部变量区、操作数栈等组成，如下图所示：

每一个方法从调用到方法返回都对应着一个栈帧入栈出栈的过程。最顶部的栈帧称为当前栈帧，栈帧所关联的方法称为当前方法，定义这个方法的类称为当前类，该线程中，虚拟机有且也只会对当前栈帧进行操作。

栈帧的作用有存储数据，部分过程结果，处理动态链接，方法返回值和异常分派。

每一个栈帧包含的内容有局部变量表、操作数栈、动态链接、方法返回地址和一些额外的附加信息。在编译代码时，栈帧需要多大的局部变量表，多深的操作数栈都可以完全确定的，并写入到方法表的code属性中。

本地方法栈(Native Stack)

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java 方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native 方法服务。

虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。

甚至有的虚拟机（譬如Sun HotSpot 虚拟机）直接就把本地方法栈和虚拟机栈合二为一。

与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError 和OutOfMemoryError异常。

程序计数器（PC Register）

在JVM的概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。

分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

JVM的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，为了各条线程之间的切换后计数器能恢复到正确的执行位置，所以每条线程都会有一个独立的程序计数器。

当线程正在执行一个Java方法，程序计数器记录的是正在执行的JVM字节码指令的地址；如果正在执行的是一个Natvie（本地方法），那么这个计数器的值则为空（Underfined）。

程序计数器占用的内存空间很少，也是唯一一个在JVM规范中没有规定任何OutOfMemoryError（内存不足错误）的区域

2.JVM堆垃圾判断

• 引用计数法

给对象添加一个引用计数器，当对象增加一个引用时计数器加 1，引用失效时计数器减 1。引用计数为 0 的对象可被回收（Python 在用，但主流虚拟机没有使用）。

优点：快，方便，实现简单。
缺陷：对象相互引用时（A.instance=B 同时 B.instance=A），很难判断对象是否该回收。

• 可达性分析

来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。

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

       当前虚拟机栈中局部变量表中的引用的对象
       方法区中类静态属性引用的对象
       方法区中的常量引用的对象

3. GC回收类型

1. Minor GC
      特点: 发生在新生代上，发生的较频繁，执行速度较快。
     触发条件: Eden 区空间不足/空间分配担保。
2. Full GC
    特点：主要发生在老年代上（新生代也会回收），较少发生，执行速度较慢。
    触发条件：
   调用 System.gc() 。
   老年代区域空间不足。
   空间分配担保失败。
   JDK 1.7 及以前的永久代(方法区)空间不足。

4.垃圾回收算法

1. 复制算法（Copying）
将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。

• 优点
  • 简单高效，不会出现内存碎片。
• 缺点
  • 内存利用率低。
  • 存活对象较多时效率明显降低，因为需要移动每个不可回收数据的内存实际位置。

注：

专门研究表明，新生代中的对象 90%是“朝生夕死”的，所以一般来说回收占据 10% 的空间够用了，所以并不需要按照 1:1 的比例来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor[1]。当回收时，将 Eden 和 Survivor 中还存活着的对象一次性地复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。
HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量的 90%（80%+10%），只有 10%的内存会被“浪费”。
 

2. 标记-清除算法（Mark-Sweep）

首先标记所有需要回收的对象，然后统一回收被标记的对象。

• 优点
  • 利用率100% 。
• 缺点
  • 标记和清除效率都不高（对比复制算法）。
  • 会产生大量不连续的内存碎片。

3. 标记-整理算法（Mark-compact）

首先标记出所有需要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端，边界以外的内存。

• 优点
  • 利用率100% 。
  • 没有内存碎片。
• 缺点
  • 标记和清除效率都不高（对比复制算法及标记清楚算法）

5、垃圾回收器

jvm 垃圾回收器把上面的三种算法全部用到了，采用分代收集。

注：

• 并行：垃圾收集的多线程的同时进行。
• 并发：垃圾收集的多线程和用户应用的多线程同时进行。
• 使用 jps -v 可以看到使用的垃圾收集器，例如：-XX:+UseConcMarkSweepGC （CMS）

6. 可以配套使用的垃圾回收器

连线表示可以 新生代 和 老年代 配套使用的垃圾收集器。

 

2. Serial/Serial Old
最古老的，单线程，独占式，成熟，适合单 CPU 服务器。-XX:+UseSerialGC 新生代和老年代都用串行收集器。

3. ParNew
ParNew 和 Serial 基本没区别，唯一的区别：多线程，多 CPU 的，停顿时间比 Serial 少 。

-XX:+UseParNewGC 新生代使用 ParNew，老年代使用 Serial Old 。

可以和CMS搭配使用。

4. Parallel Scavenge（ParallerGC）/Parallel Old
关注吞吐量的垃圾收集器，高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那有吞吐效率就是 99% 。

5. CMS（Concurrent Mark Sweep）
收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。

CMS 收集器就非常符合这类应用的需求。-XX:+UseConcMarkSweepGC ，一般新生代使用 ParNew，老年代的用 CMS，从名字（包含“Mark Sweep”）上就可以看出，CMS 收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些。

回收过程

整个过程分为 4 个步骤，包括：

1、初始标记：仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，需要停顿（STW -Stop the world）。

2、并发标记：从 GC Root 开始对堆中对象进行可达性分析，找到存活对象，它在整个回收过程中耗时最长，不需要停顿。

3、重新标记：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿(STW)。这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

并发清除：不需要停顿。
优缺点

1、优点

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS 收集器的内存回收过程是与用户线程一起并发执行的

2、缺点

CPU 资源敏感：因为并发阶段多线程占据 CPU 资源，如果 CPU 资源不足，效率会明显降低。
由于 CMS 并发清理阶段 用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS 无法在当次收集中处理掉它们，只好留待下一次 GC 时再清理掉。这一部分垃圾就称为 浮动垃圾。
由于浮动垃圾的存在，因此需要预留出一部分内存，意味着 CMS 收集不能像其它收集器那样等待老年代快满的时候再回收。在 1.6 的版本中老年代空间使用率阈值(92%)，如果预留的内存不够存放浮动垃圾，就会出现 Concurrent Mode Failure，这时虚拟机将临时启用 Serial Old 来替代 CMS。
会产生内存碎片：标记-清除算法 会导致产生不连续的内存碎片。
6. G1
G1相比较CMS的改进

基于标记-整理算法, 不会产生空间碎片，分配大对象时不会无法得到连续的空间而提前触发一次full gc 。
停顿时间可控： G1可以通过设置预期停顿时间（Pause time）来控制垃圾收集时间，但是这个预期停顿时间G1只能尽量做到，而不是一定能做到。
可预测的停顿：

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

G1的设置参数

-XX:+UseG1GC // 开启G1
-XX:MaxGCPauseMillis=200 // 预期停顿时间200毫秒，默认也是200
-XX:G1HeapRegionSize=2 // 设置每个区域大小2M，其必须是2的幂，范围允许为1Mb到32Mb
-XX:G1NewSizePercent // 新生代最小值，默认值 5%
-XX:G1MaxNewSizePercent // 新生代最大值，默认值 60%
-XX:ParallelGCThreads // STW 期间，并行 GC 线程数
-XX:ConcGCThreads=n // 并发标记阶段，并行执行的线程数
G1是怎么划堆内存的呢

G1 把堆划分成多个大小相等的 独立区域（Region），新生代和老年代不再物理隔离。

G1 算法将堆划分为若干个独立区域（Region），它仍然属于分代收集器。不过，这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者 Survivor 空间。例如其中一个独立区域如图：

GC 的模式

1、Young GC

Young GC 主要是对 Eden 区进行 GC，它在 Eden 空间耗尽时会被触发。在这种情况下，Eden 空间的数据移动到 Survivor 空间中，如果 Survivor 空间不够，Eden 空间的部分数据会直接晋升到老年代空间。Survivor 区的数据移动到新的 Survivor 区中，也有部分数据晋升到老年代空间中。最终 Eden 空间的数据为空，GC 停止工作，应用线程继续执行

2、Mixed GC

选定所有新生代里的 Region，外加根据 global concurrent marking 统计得出收集收益高的若干老年代 Region。在用户指定的开销目标范围内尽可能选择益高的老年代 Region。Mixed GC 不是 full GC，它只能回收部分老年代的 Region。如果 mixed GC 实在无法跟上程序分配内存的速度，导致老年代填满无法继续进行 Mixed GC，就会使用 serial old GC（full GC）来收集整个 GC heap。所以我们可以知道，G1 是不提供 full GC 的
收集过程

大致分为4个步骤：

1、初始标记：仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改 TAMS（Nest Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以的 Region 中创建对象，此阶段需要停顿线程(STW)，但耗时很短

2、并发标记：从 GC Root 开始对堆中对象进行可达性分析，找到存活对象，此阶段耗时较长，但可与用户程序并发执行

3、最终标记：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中。这阶段需要停顿线程(STW)，但是可并行执行

4、筛选回收：首先对各个 Region 中的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率

7、垃圾回收器的一些重要参数

 

8 JVM参数设置

‐Xms3072M   
‐Xmx3072M   
‐Xmn2048M   
‐Xss1M   
‐XX:MetaspaceSize=256M   
‐XX:MaxMetaspaceSize=256M   
‐XX:SurvivorRatio=8    
‐XX:MaxTenuringThreshold=5   
‐XX:PretenureSizeThreshold=1M   
‐XX:+UseParNewGC   
‐XX:+UseConcMarkSweepGC   
‐XX:CMSInitiatingOccupancyFraction=70   
‐XX:+UseCMSInitiatingOccupancyOnly   
‐XX:+AlwaysPreTouch

参数解释

1.‐Xms3072M ‐Xmx3072M 最小最大堆设置为3g，最大最小设置为一致防止内存抖动

2.‐Xss1M 线程栈1m

3.‐Xmn2048M ‐XX:SurvivorRatio=8 年轻代大小2g，eden与survivor的比例为8:1:1，也就是1.6g:0.2g:0.2g

4.-XX:MaxTenuringThreshold=5 年龄为5进入老年代 5.‐XX:PretenureSizeThreshold=1M 大于1m的大对象直接在老年代生成

6.‐XX:+UseParNewGC ‐XX:+UseConcMarkSweepGC 使用ParNew+cms垃圾回收器组合

7.‐XX:CMSInitiatingOccupancyFraction=70 老年代中对象达到这个比例后触发fullgc

8.‐XX:+UseCMSInitiatinpOccupancyOnly  老年代中对象达到这个比例后触发fullgc，每次

9.‐XX:+AlwaysPreTouch 强制操作系统把内存真正分配给IVM，而不是用时才分配。

9.配置OOM时候的内存dump文件和GC日志

额外增加了GC日志打印、OOM自动dump等配置内容，帮助进行问题排查

-XX:+HeapDumpOnOutOfMemoryError

在Out Of Memory，JVM快死掉的时候，输出Heap Dump到指定文件。

不然开发很多时候还真不知道怎么重现错误。

路径只指向目录，JVM会保持文件名的唯一性，叫java_pid${pid}.hprof。

-XX:+HeapDumpOnOutOfMemoryError   

-XX:HeapDumpPath=${LOGDIR}/

因为如果指向特定的文件，而文件已存在，反而不能写入。

输出4G的HeapDump，会导致IO性能问题，在普通硬盘上，会造成20秒以上的硬盘IO跑满，

需要注意一下，但在容器环境下，这个也会影响同一宿主机上的其他容器。

GC的日志的输出也很重要：

-Xloggc:/dev/xxx/gc.log   

-XX:+PrintGCDateStamps   

-XX:+PrintGCDetails

GC的日志实际上对系统性能影响不大，打日志对排查GC问题很重要。

一份通用的JVM参数模板

一般来说，大企业或者架构师团队，都会为项目的业务系统定制一份较为通用的JVM参数模板，但是许多小企业和团队可能就疏于这一块的设计，如果老板某一天突然让你负责定制一个新系统的JVM参数，你上网去搜大量的JVM调优文章或博客，结果发现都是零零散散的、不成体系的JVM参数讲解，根本下不了手，这个时候你就需要一份较为通用的JVM参数模板了，不能保证性能最佳，但是至少能让JVM这一层是稳定可控的，

在这里给大家总结了一份模板：

基于4C8G系统的ParNew+CMS回收器模板（响应优先），新生代大小根据业务灵活调整！

-Xms4g  
-Xmx4g  
-Xmn2g  
-Xss1m  
-XX:SurvivorRatio=8  
-XX:MaxTenuringThreshold=10  
-XX:+UseConcMarkSweepGC  
-XX:CMSInitiatingOccupancyFraction=70  
-XX:+UseCMSInitiatingOccupancyOnly  
-XX:+AlwaysPreTouch  
-XX:+HeapDumpOnOutOfMemoryError  
-verbose:gc  
-XX:+PrintGCDetails  
-XX:+PrintGCDateStamps  
-XX:+PrintGCTimeStamps  
-Xloggc:gc.log

如果是GC的吞吐优先，推荐使用G1，基于8C16G系统的G1回收器模板：

G1收集器自身已经有一套预测和调整机制了，因此我们首先的选择是相信它，

即调整-XX:MaxGCPauseMillis=N参数，这也符合G1的目的——让GC调优尽量简单！

同时也不要自己显式设置新生代的大小（用-Xmn或-XX:NewRatio参数），

如果人为干预新生代的大小，会导致目标时间这个参数失效。

-Xms8g  
-Xmx8g  
-Xss1m  
-XX:+UseG1GC  
-XX:MaxGCPauseMillis=150  
-XX:InitiatingHeapOccupancyPercent=40  
-XX:+HeapDumpOnOutOfMemoryError  
-verbose:gc  
-XX:+PrintGCDetails  
-XX:+PrintGCDateStamps  
-XX:+PrintGCTimeStamps  
-Xloggc:gc.log

 

针对-XX:MaxGCPauseMillis来说，参数的设置带有明显的倾向性：调低↓：延迟更低，但MinorGC频繁，MixGC回收老年代区减少，增大Full GC的风险。调高↑：单次回收更多的对象，但系统整体响应时间也会被拉长。

针对InitiatingHeapOccupancyPercent来说，调参大小的效果也不一样：调低↓：更早触发MixGC，浪费cpu。调高↑：堆积过多代回收region，增大FullGC的风险。

10.调优总结

系统在上线前的综合调优思路：

1、业务预估：根据预期的并发量、平均每个任务的内存需求大小，然后评估需要几台机器来承载，每台机器需要什么样的配置。

2、容量预估：根据系统的任务处理速度，然后合理分配Eden、Surivior区大小，老年代的内存大小。

3、回收器选型：响应优先的系统，建议采用ParNew+CMS回收器；吞吐优先、多核大内存(heap size≥8G)服务，建议采用G1回收器。

4、优化思路：让短命对象在MinorGC阶段就被回收（同时回收后的存活对象<Survivor区域50%，可控制保留在新生代），长命对象尽早进入老年代，不要在新生代来回复制；尽量减少Full GC的频率，避免FGC系统的影响。

5、到目前为止，总结到的调优的过程主要基于上线前的测试验证阶段，所以我们尽量在上线之前，就将机器的JVM参数设置到最优！

JVM调优只是一个手段，但并不一定所有问题都可以通过JVM进行调优解决，大多数的Java应用不需要进行JVM优化，我们可以遵循以下的一些原则：

• 上线之前，应先考虑将机器的JVM参数设置到最优；

• 减少创建对象的数量（代码层面）；

• 减少使用全局变量和大对象（代码层面）；

• 优先架构调优和代码调优，JVM优化是不得已的手段（代码、架构层面）；

• 分析GC情况优化代码比优化JVM参数更好（代码层面）；

通过以上原则，我们发现，其实最有效的优化手段是架构和代码层面的优化，而JVM优化则是最后不得已的手段，也可以说是对服务器配置的最后一次“压榨”。

参考：阿里技术面：每天100w次登陆请求, 8G 内存该如何设置JVM参数？_程序员的成长之路的博客-CSDN博客

JVM 垃圾回收算法和垃圾回收器_如来神掌十八式的博客-CSDN博客