JVM层GC调优（上）

JVM内存结构简介（jdk1.8）

JVM层的GC调优是生产环境上必不可少的一个环节，由于咱们须要肯定这个进程能够占用多少内存，以及设定一些参数的阀值。以此来优化项目的性能和提升可用性，并且这也是在面试中常常会被问到的问题。

想要进行GC调优，咱们首先须要简单了解下JVM的内存结构，Java虚拟机的规范文档以下：

https://docs.oracle.com/javase/specs/jvms/se8/html/index.html

在介绍JVM内存结构以前，咱们须要先知道运行时数据区这样的一个东西，它与JVM的内存结构有着必定的关联。不过它属因而一个规范，因此与JVM内存结构是有着物理上的区别的。运行时数据区以下：

1.程序计数器（Program Count Register，简称PC Register）：

• JVM支持多线程同时执行，每个线程都有本身的PC Register。当每个新线程被建立时，它都将获得它本身的PC Register。线程正在执行的方法叫作当前方法。若是执行的是Java方法，那么PC Register里存放的就是当前正在执行的指令的地址，若是是native方法（C/C++编写的方法），则是为空。此内存区域是惟一一个在java虚拟机规范中没有规定任何OutOfMemoryError状况的区域。

2.虚拟机栈（JVM Stacks）：

• Java虚拟机栈（Java Virtual Machine Stacks）是线程私有的，它的生命周期与线程相同。虚拟机描述的是Java方法执行的内存模型：每一个方法在执行的同时都会建立一个栈帧，用于存储局部变量表、操做数栈、动态连接、方法出口等信息。每个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程，实际上就是所谓的线程堆栈。
• 局部变量表存放了各类基本类型、对象引用和returnAddress类型（指向了一条字节码指令地址）。其中64位长度 long 和 double 占两个局部变量空间，其余只占一个。
• 该区域中规定的异常状况有两种：1.线程请求的栈的深度大于虚拟机所容许的深度，将抛出StackOverflowError异常；2.若是虚拟机能够动态扩展，若是扩展时没法申请到足够的内存，就抛出OutOfMemoryError异常。

3.堆Heap：

• Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。堆是被全部线程共享的一块内存区域，在虚拟机启动时建立。此内存区域的惟一目的就是存放对象实例，几乎全部的对象实例都在这里分配内存。
• Java堆能够处于物理上不连续的内存空间中，只要逻辑上是连续的便可。堆中可细分为新生代和老年代，再细分可分为Eden空间、From Survivor空间、To Survivor空间。堆没法扩展时，会抛出OutOfMemoryError异常。

4.方法区（Method Area）：

• 方法区与Java堆同样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，可是它却有一个别名叫作Non-Heap（非堆），目的是与Java堆区分开来。
• 当方法区没法知足内存分配需求时，抛出OutOfMemoryError

5.运行时常量池（Run-Time Constant Pool）：

• 如上图所描述的同样，它是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项是常量池（Const Pool Table），用于存放编译期生成的各类字面量和符号引用，这部份内容将在类加载后被放入方法区的运行时常量池中存储。并不是预置入Class文件中常量池的内容才进入方法运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的即是String类的intern()方法。
• 一样的，当方法区没法知足内存分配需求时，也会抛出OutOfMemoryError

6.本地方法栈（Native Method Stacks）：

• 本地方法栈与虚拟机栈所发挥的做用是很是类似的，它们之间的区别不过是虚拟机栈为虚拟机执行Java方法（字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。

---

了解了运行时方法区规范后，咱们接下来看看JVM的内存结构图：

如上图，能够看到JVM内存被分为了两大区，非堆区用于存储对象之外的数据：

• Metaspace：存放Class、Package、Method、Field、字节码、常量池、符号引用等等
  • CCS：这个区域存放32位指针的Class，也就是压缩类空间，默认关闭，须要使用JVM参数开启
  • CodeCache：存放JIT编译后的本地代码以及JNI使用的C/C++代码

而堆区则用于存储对象相关数据：

• Young：新生代，存放新的或只通过几回Minor GC的对象
  • Eden：存放最新建立的对象，一些较大的对象则会特殊处理
  • S0/S1：当对象通过第一次Minor GC后，若是仍然存活，就会存放到这里。须要注意的是，S0和S1区域在同一时间上，只有其中一个是有数据的，而另外一个则是空的。
• Old：老年代，当S0或S1区域存满对象了，就会把这些对象存放到这个old区域中

在图中也能够看到，堆区还被分为了年轻代（young）和老年代（old）。那么为何会有年轻代：

咱们先来捋一捋，为何须要把堆区分代？不分代不能完成它所作的事情么？其实不分代也彻底能够，分代的惟一理由就是优化GC性能。你先想一想，若是没有分代，那咱们全部的对象都会存在同一个空间里。当进行GC的时候，咱们就要找到哪些对象是没有用的，这样一来就须要对整个堆区进行扫描。而咱们的不少对象都是只存活一瞬间的，因此GC就会比较频繁，而每次GC都得扫描整个堆区，就会致使性能低下。不进行GC的话，又会致使内存空间很快被占满。

由于GC性能的缘由，因此咱们才须要对堆区进行分代。若是进行分代的话，咱们就能够把新建立的对象专门存放到一个单独的区域中，当进行GC的时候就优先把这块存放“短命”对象的区域进行回收，这样就会腾出很大的空间出来，而且因为不用去扫描整个堆区，也能极大提升GC的性能。

年轻代中的GC：

从上图中也能够看到年轻代被分为了三部分：1个Eden区和2个Survivor区，通常咱们都会简称为S0、S1（同时它们还分为from和to两种角色），默认比例为8:1。通常状况下，最新建立的对象都会被分配到Eden区(一些大对象会特殊处理)，这些对象通过第一次Minor GC后，若是仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增长1岁，当它的年龄增长到必定程度时，就会被移动到年老代中。

由于年轻代中的对象基本都是"短命"的(80%以上)，因此在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另一块上面。因此才会有S0和S1区，复制算法的优势就是吞吐量高、可实现高速分配而且不会产生内存碎片，因此才适用于做为年轻代的GC算法。

在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中全部存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到必定值(年龄阈值，能够经过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。通过此次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。无论怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满以后，会将全部对象移动到年老代中。

JVM中的对象分配：

• 对象优先在Eden区分配
• 大对象则会直接进入老年代

---

咱们了解完JVM内存结构后，再来看看一些经常使用的JVM参数：

1.设置年轻代的大小，和年轻代的最大值，具体的值须要根据实际业务场景进行判断。若是存在大量临时对象就能够设置大一些，不然小一些，通常为整个堆大小的1/3或者1/4。为了防止年轻代的堆收缩，两个参数的值需设为同样大：

• -XX:NewSize
• -XX:MaxNewSize

2.设置Metaspace的大小，和Metaspace的最大值，一样需设为同样大：

• -XX:MetaspaceSize
• -XX:MaxMetaspaceSize

3.设置Eden和其中一个Survivor的比例，这个值也比较重要：

• -XX:SurvivorRatio

4.设置young和old区的比例：

• -XX:NewRatio

5.这个参数用于显示每次Minor GC时Survivor区中各个年龄段的对象的大小：

• -XX:+PrintTenuringDistribution

6.用于设置晋升到老年代的对象年龄的最小值和最大值，每一个对象在坚持过一次Minor GC以后，年龄就加1：

• -XX:InitialTenuringThreshol
• -XX:MaxTenuringThreshold

7.使用短直针，也就是启用压缩类空间（CCS）：

• -XX:+UseCompressedClassPointers

8.设置CCS空间的大小，默认是一个G：

• -XX:CompressedClassSpaceSize

9.设置CodeCache的一个初始大小：

• -XX:InitialCodeCacheSize

10.设置CodeCache的最大值：

• -XX:ReservedCodeCacheSize

11.设置多大的对象会被直接放进老年代：

• -XX:PretenureSizeThreshold

12.长期存活的对象会被放入Old区，使用如下参数设置就能够设置对象的最大存活年龄：

• -XX:MaxTenuringThreshold

注：若是设置为0的话，则年轻代对象不通过Survivor区，直接进入年老代。对于年老代比较多的应用，能够提升效率。若是将此值设置为一个较大值，则年轻代对象会在Survivor区进行屡次复制，这样能够增长对象再年轻代的存活时间，增长在年轻代即被回收的概论，linux64的java6默认值是15：

13.设置Young区每发生GC的时候，就打印有效的对象的岁数状况：

• -XX:+PrintTenuringDistribution

14.设置Survivor区发生GC后对象所存活的比例值：

• -XX:TargetSurvivorRatio

---

常见垃圾回收算法

本小节咱们来简单介绍一些常见的垃圾回收算法，众所周知Java区别与C/C++的一点就是，Java是能够自动进行垃圾回收的。因此在Java中的内存泄露概念和C/C++中的内存泄露概念不同。在Java中，一个对象的指针一直被应用程序所持有得不到释放就属因而内存泄露。而C/C++则是把对象指针给弄丢了，该对象就永远没法获得释放，这就是C/C++里的内存泄露。

在进行垃圾回收的是时候，要如何确认一个对象是不是垃圾呢？在好久之前有一种方式就是使用引用计数，当一个对象指针被其余对象所引用时就会进行一个计数。在进行垃圾回收时，只要这个计数存在，那么就会判断该对象就是存活的。而没有引用计数的对象，就会被判断为垃圾，能够进行回收。可是这种方法缺陷很明显，计数会占用资源不说，若是当一个A对象和一个B对象互相持有对方引用时，那么这两个对象的引用计数都不会为0，就永远不会被回收掉，这样就会致使内存泄露的问题。

在Java中，则是采用枚举根节点的方式：

• 思想：枚举根节点，作可达性分析
• 根节点：能够是类加载器、Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法栈的变量等等

如上图，JVM会从根节点开始遍历引用，只要顺着引用路线所遍历到的对象都会判断为存活对象，便是具备可达性的，这些对象就不会被回收。而没有被遍历到的对象，也就是图中的E和F对象，即使它们俩互相都还存在引用，也会被回收掉，由于它们不存在根节点的引用路线中，便是不具备可达性的。

---

既然了解了JVM如何判断一个对象是否为垃圾后，咱们就能够来看看一些垃圾回收算法了：

1.标记-清除：

• 算法：该算法分为“标记” 和 “清除” 两个阶段：首先标记出全部须要回收的对象，在标记完成后统一进行回收
• 缺点：效率不高，标记和清除两个过程的效率都不高。容易产生内存碎片，碎片太多就会致使提早GC。

2.复制算法：

• 算法：它将可用内存按容量划分为大小相等的两个块，每次只使用其中的一块。当这一块内存用完了，就将还存活的对象复制到另外一个块上，而后再把已使用过的内存空间一次清理掉。
• 优缺点：实现简单，运行高效，吞吐量大，可是空间利用率低，一次只能利用50%

3.标记-整理：

• 算法：标记过程仍然与 “标记-清除” 算法同样，当后续步骤不是直接对可回收对象进行清理，而是让全部存活的对象都向一端移动，而后直接清理掉边界之外的内存。
• 优缺点：没有了内存碎片，可是整理内存比较耗时

4.分代垃圾回收：

• 算法：这就是目前JVM所使用的垃圾回收算法，能够看到以上所介绍到的算法都各自有优缺点。而JVM就是把这些算法都整合了起来，在不一样的区域使用不一样的垃圾回收算法。Young区使用复制算法，Old区则使用标记清除或者标记整理算法。

---

垃圾收集器

在上一小节了解了一些常见的垃圾回收算法后，咱们再来看看JVM中常见的垃圾收集器：

• 1.串行收集器Serial：Serial、Serial Old
• 2.并行收集器Parallel：Parallel Scavenge、Parallel Old，吞吐量优先，是Server模式下的默认收集器。默认在内存大于2G，CPU核心数大于2核的环境下为Server模式
• 3.并发收集器Concurrent：CMS、G1，停顿时间优先

注：串行收集器几乎不会在web应用中使用，因此主要介绍并行和并发收集器

串行 VS 并行 VS 并发：

• 串行（Serial）：指只有单个垃圾收集线程进行工做，也就是单线程的，当垃圾收集线程启动的时候，用户线程会处于一个等待状态。适合内存较小的嵌入式开发中
• 并行（Parallel）：指多条垃圾收集线程并行工做，但此时用户线程仍然处于等待状态。适合科学计算、后台处理等弱交互场景
• 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不必定是并行的，可能会交替执行），垃圾收集线程在执行的时候不会停顿用户程序的运行。适合对响应时间有要求、交互性强的场景，好比Web开发

停顿时间 VS 吞吐量：

• 停顿时间：指垃圾收集器在进行垃圾回收时所中断应用执行的时间。可使用如下参数进行设置：
  • -XX:MaxGCPauseMillis
• 吞吐量：指花在垃圾收集的时间和花在应用时间的占比。可使用如下参数进行设置：
  • -XX:GCTimeRatio=< n > 垃圾收集时间占：1/1+n

开启串行收集器：

• -XX:+UseSerialGC（Young区）
• -XX:+UseSerialOldGC（Old区）

开启并行收集器:

• -XX:+UseParallelGC（Young区）
• -XX:+UseParallelOldGC（Old区）
• -XX:ParallelGCThread=< N > 设置N个GC线程，N取决于CPU核心数

并发收集器在JDK1.8里有两个，一个是CMS，CMS由于具备响应时间优先的特色，因此是低延迟、低停顿的，CMS是老年代收集器。开启该收集器的参数以下：

• -XX:+UseParNewGC（Young区）
• -XX:+UseConcMarkSweepGC（Old区）

另外一个是G1，开启该收集器的参数以下：

• -XX:+UseG1GC（Young区、Old区）

垃圾收集器搭配图：

注：实线表明可搭配使用的，虚线表示当内存分配失败的时候CMS会退化成SerialOld。JDK1.8中建议使用的是G1收集器

有这么多的垃圾收集器，那么咱们要如何去选择合适的垃圾收集器呢？这个是没有具体答案的，都得按照实际的场景进行选择，但通常都会按照如下原则来进行选择：

• 优先调整堆的大小让服务器本身来选择
• 若是内存小于100M，使用串行收集器
• 如何是单核，而且没有停顿时间的要求，就可使用串行或由JVM本身选择
• 若是容许停顿时间超过1秒，选择并行或者JVM本身选择
• 若是响应时间最重要，而且不能超过1秒，则使用并发收集器

---

其中并行收集器是支持自适应的，经过设置如下几个参数，并行收集器会以停顿时间优先去动态调整参数：

• -XX:MaxGCPauseMillis=< N >
• -XX:GCTimeRatio=< N >
• -Xmx< N >

当内存不够的时候并行收集器能够动态调整内存，虽然实际生产环境中用的比较少，至于每次动态调整多少内存，则使用如下参数进行设置：

• -XX:YoungGenerationSizeIncrement=< Y > （增长，Young区，默认20%）
• -XX:TenuredGenerationSizeIncrement=< T > （增长，Old区，默认20%）
• -XX:AdaptiveSizeDecrementScaleFactor=< D >（减小，默认4%）

---

了解了并行收集器后，咱们来简单看看CMS收集器其余的一些特性以及相关调优参数。

CMS垃圾收集过程：

• 1.CMS initial mark：初识标记Root，STW
• 2.CMS concurrent mark：并发标记
• 3.CMS-concurrent-preclean：并发预清理
• 4.CMS remark：从新标记，STW
• 5.CMS concurrent sweep：并发清除
• 6.CMS concurrent-reset：并发重置

CMS的缺点：

• CPU敏感
• 会产生浮动垃圾
• 会产生空间碎片

CMS的相关调优参数：

设置并发的GC线程数：

• -XX:ConcGCThreads

开启如下参数能够在Full GC以后对内存进行一个压缩，以此减小空间碎片：

• -XX:+UseCMSCompactAtFullCollection

这个参数则是设置多少次Full GC以后才进行压缩：

• -XX:CMSFullGCsBeforeCompaction

设置Old区存满多少对象的时候触发Full GC，默认值为92%：

• -XX:CMSInitiatingOccupancyFraction

启用该参数表示不可动态调整以上参数的值：

• -XX:+UseCMSInitiatingOccupancyOnly

启用该参数表示在Full GC以前先作Young GC：

• -XX:+CMSScavengeBeforeRemark

在jdk1.7以前可使用如下参数，启用回收Perm区：

• -XX:+CMSClassUnloadingEnable

---

在jdk1.8后，推荐使用的垃圾收集器是G1。G1收集器在jdk1.7中第一次出现，因此到了jdk1.8里就很是成熟了。

G1收集器官网介绍以下：

The Garbage-First (G1) garbage collector is fully supported in Oracle JDK 7 update 4 and later releases. The G1 collector is a server-style garbage collector, targeted for multi-processor machines with large memories. It meets garbage collection (GC) pause time goals with high probability, while achieving high throughput. Whole-heap operations, such as global marking, are performed concurrently with the application threads. This prevents interruptions proportional to heap or live-data size.

The first focus of G1 is to provide a solution for users running applications that require large heaps with limited GC latency. This means heap sizes of around 6GB or larger, and stable and predictable pause time below 0.5 seconds.

官方文档地址：

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html

原理概述：

G1 也是属于分代收集器的，可是G1的分代是逻辑上的，而不是物理上的

G1 将整个对区域划分为若干个Region，每一个Region的大小是2的倍数（1M,2M,4M,8M,16M,32M，经过设置堆的大小和Region数量计算得出。

Region区域划分与其余收集相似，不一样的是单独将大对象分配到了单独的region中，会分配一组连续的Region区域（Humongous start 和 humonous Contoinue 组成），因此一共有四类Region（Eden，Survior，Humongous和Old），G1 做用于整个堆内存区域，设计的目的就是减小Full GC的产生。在Full GC过程当中因为G1 是单线程进行，会产生较长时间的停顿。

G1的OldGc标记过程能够和yongGc并行执行，可是OldGc必定在YongGc以后执行，即MixedGc在yongGC以后执行。

结构图：

G1垃圾收集算法主要应用在多CPU大内存的服务中，在知足高吞吐量的同时，尽量的知足垃圾回收时的暂停时间，该设计主要针对以下应用场景：

• 垃圾收集线程和应用线程并发执行，和CMS同样
• 空闲内存压缩时避免冗长的暂停时间
• 应用须要更多可预测的GC暂停时间
• 不但愿牺牲太多的吞吐性能

G1的几个概念：

• Region：G1收集器所划分的内存区域
• SATB：Snapshot-At-TheBeginning，它是经过Root Tracing获得的，GC开始时候存活对象的快照
• RSet：记录了其余Region中的对象，引用本Region中对象的关系，属于points-into结构（谁引用了个人对象）

G1中的Young GC过程，和以往的是同样的：

• 新对象进入Eden区
• 存活对象拷贝到Survivor区
• 存活时间达到年龄阈值时，对象晋升到Old区

可是G1中没有Full GC，取而代之的是Mixed GC：

• 它不是Full GC，因此触发Mixed GC时回收的是全部的Young区和部分Old区的垃圾

G1里还有一个概念叫全局并发标记（global concurrent marking），和CMS的并发标记是相似的：

• 1.Initial marking phase：标记GC Root，STW
• 2.Root region scanning phase：根区扫描
• 3.Concurrent marking phase：并发标记存活对象
• 4.Remark phase：从新标记，STW
• Cleanup phase：部分STW

G1相关调优参数：

设置堆占有率达到这个参数值则触发global concurrent marking，默认值为45%：

• -XX:InitiatingHeapOccupancyPercent

设置在global concurrent marking结束以后，能够知道Region里有多少空间要被回收，在每次YGC以后和再次发生Mixed GC以前，会检查垃圾占比是否达到此参数的值，只有达到了，下次才会发生Mixed GC：

• -XX:G1HeapWastePercent

设置Old区的Region被回收时的存活对象占比：

• -XX:G1MixedGCLiveThresholdPercent

设置一次global concurrent marking以后，最多执行Mixed GC的次数：

• -XX:G1MixedGCCountTarget

设置一次Mixed GC中能被选入CSet的最多Old区的Region数量：

• -XX:G1OldCSetRegionThresholdPercent

其余参数：

• -XX:+UseG1GC //开启G1收集器
• -XX:G1HeapRegionSize=n //设置Region的大小，大小范围：1-32M，数量上限：2048个
• -XX:MaxGCPauseMillis=200 //设置最大停顿时间
• -XX:G1NewSizePercent //设置Young区大小
• -XX:G1MaxNewSizePercent //设置Young区最大占整个Java Heap的大小，默认值为60%
• -XX:G1ReservePercent=10 //保留防止to space溢出
• -XX:ParallelGCThreads=n //设置SWT线程数
• -XX:ConcGCThreads=n //并发线程数=1/4*并行

注意事项：

• 年轻代大小：避免使用-Xmn、-XX:NewRatio等显式设置Young区大小，会覆盖暂停时间目标
• 暂停时间目标：暂停时间不要太严苛，其吞吐量目标是90%的应用程序时间和10%的垃圾回收时间，太严苛会直接影响到吞吐量

至因而否须要切换到G1收集器，能够根据如下原则进行选择：

• 50%以上的堆被存活对象占用
• 对象分配和晋升的速度变化很是大
• 垃圾回收时间特别长，超过了1秒

关于在Web应用中，如何判断一个垃圾收集器的好坏，主要是看如下两点，如下两点都需为优才是好的垃圾收集器：

• 1.响应时间
• 2.吞吐量

下一篇：

• JVM层GC调优（下）