大纲 。

1.JVM GC导致系统突然卡死无法访问 。

2.什么是Young GC什么是Full GC 。

3.Young GC、Old GC和Full GC的发生情况 。

4.频繁YGC的案例(G1解决大内存YGC过慢) 。

5.频繁FGC的案例(YGC存活对象S区放不下) 。

6.问题汇总 。

  。

1.JVM GC导致系统突然卡死无法访问 。

(1)基于JVM运行的系统最怕什么 。

(2)新生代GC多久一次才对系统影响不大 。

(3)什么时候新生代GC对系统影响很大 。

(4)如何处理大内存机器新生代GC过慢 。

(5)要命的频繁老年代GC问题 。

(6)JVM性能优化到底在优化什么 。

  。

(1)基于JVM运行的系统最怕什么 。

一.JVM运行时最核心的内存区域其实是堆内存 。

在堆内存中会放业务系统创建出来的各种对象，而且通常都会将堆内存划分为新生代和老年代两个内存区域。对象一般都会优先放在新生代中，如下图示:

二.随着系统不断地运行，会有越来越多的对象放入新生代中 。

然后新生代快占满，放不下更多对象时，就要清理新生代的垃圾对象了。所谓的垃圾对象就是没有被GC Roots引用的对象，所谓的GC Roots就是类的静态变量、方法的局部变量等.

  。

代码中最常创建对象的地方，就是在方法里。而一个方法一旦执行完毕，那么该方法里的局部变量就没了。之前在方法里创建出来的对象就会成为垃圾对象，因为没有再被引用了。在新生代中，99%的对象都是这种没有再被引用的垃圾对象.

  。

三.在新生代快要占满时，就会触发新生代GC，对新生代进行垃圾回收 。

新生代会通过复制算法进行回收。通常来说新生代会有一块Eden区用来创建对象，默认占据80%的内存。还有两块Survivor区用来放垃圾回收后存活的对象，分别占10%的内存。如下图示:

需要注意的是：对新生代进行垃圾回收时，需要停止系统程序的运行，不要让系统程序执行任何代码逻辑，也就是所谓的Stop the World。此时只允许垃圾回收器的多个垃圾回收线程去进行垃圾回收，如下图示:

新生代通过复制算法进行回收时:

首先会对所有的GC Roots进行追踪，标记出所有被GC Roots直接或者间接引用的对象。被标记成GC Roots引用的对象就是存活对象，比如上图有个类的静态变量就引用了一个对象，那个对象就是存活对象。然后就会把存活对象都转移到一块Survivor区域里去，比如上图中，就把存活的对象转移到一块Survivor区里了。接着就会直接把Eden区里的对象全部回收掉，释放其内存空间，然后就可以恢复系统程序的运行。如下图示:

四.由此可见，这里有一个很大的问题——停止系统程序的问题 。

当新生代被占满，需要进行垃圾回收时，就要停止系统程序的运行。这就是基于JVM运行的系统最害怕的问题：系统卡顿问题。假设一次新生代垃圾回收要20ms，那么在这20ms内系统是无法工作的。此时用户对系统发送的请求，在这20ms内是无法处理的，会卡住20ms.

  。

(2)新生代GC多久一次才对系统影响不大 。

新生代GC对系统的性能影响到底大不大？通常来说是不大的，而且新生代GC也几乎没什么好调优的。因为它的运行逻辑非常简单，就是Eden区一旦满了就会触发一次GC.

  。

一.如果非要对新生代GC进行调优，只要给系统分配足够内存即可 。

所以核心点还是在于堆内存的分配、新生代内存的分配。如果内存足够的话，系统可能在低峰期几个小时才会有一次新生代GC，而在高峰期最多也就几分钟一次新生代GC.

  。

一般的业务系统都会部署在2核4G或4核8G的机器上，此时分配给堆的内存不会超3G，给新生代中的Eden区的内存大概是1G.

  。

二.而且新生代采用的复制算法效率极高 。

因为新生代里存活的对象很少，所以可以迅速标记出这少量存活对象。然后再将存活对象移动到Survivor区，接着回收全部垃圾对象。整个标记 -> 移动 -> 回收的速度很快(小内存ParNew + 大内存G1).

  。

通常来说，一次新生代GC可能也就耗费几毫秒～几十毫秒。假如系统运行时每隔几分或几十分执行一次新生代GC，卡顿几十毫秒。尽管这几十毫秒期间的请求会出现卡顿，但此时用户几乎是无感知的，所以新生代GC一般对系统性能影响不大.

  。

(3)什么时候新生代GC对系统影响很大 。

当系统部署在大内存机器上时，新生代GC会对系统影响会很大。比如系统部署在32核64G的机器上，分配给JVM的内存就有几十G，那么新生代的Eden区可能就会有30~40G的内存.

  。

Kafka、Elasticsearch等大数据相关系统，会部署在大内存的机器上。如果系统负载非常高，比如每秒几万的访问请求发到Kafka、ES上，那么就可能会导致Eden区几十G内存迅速被占满而触发垃圾回收.

  。

假设1分钟就会占满新生代，然后需要执行GC，每次GC需要几秒钟。那么由于每次进行垃圾回收时都要暂停Kafka、ElasticSearch的运行，所以会发现每隔一分钟，Kafka、ElasticSearch系统就要卡顿几秒钟。甚至有的请求一旦卡住几秒就会超时报错，从而导致系统频繁出错.

  。

(4)如何处理大内存机器新生代GC过慢 。

那么应该如何解决这种几十G大内存机器的新生代GC过慢的问题呢？答案是使用G1垃圾回收器.

  。

可以对G1垃圾回收器设置一个期望的每次GC的停顿时间，比如20ms。那么G1就会基于它的Region内存划分原理，在运行一段时间后，就只针对比如2G内存的Region进行垃圾回收，此时只需停顿20ms，然后回收掉2G内存空间，腾出内存后，接着继续让系统运行.

  。

G1天生就适合这种大内存JVM的运行，G1能完美解决大内存垃圾回收时间过长的问题.

  。

(5)要命的频繁老年代GC问题 。

综上所述，新生代GC一般不会有太大问题。真正有问题的是，频繁触发老年代GC.

  。

一.对象进入老年代的条件 。

年龄太大 + 动态年龄判断规则 + 新生代GC后存活对象太多无法放入S区.

  。

第一：对象年龄太大了 。

这种对象一般很少，基本是系统中要长期存在的核心组件，不需要回收。这些核心组件对象，在新生代熬过默认15次垃圾回收后就会进入老年代.

  。

第二：动态年龄判定规则 。

如果一次新生代GC后，发现S区的几个年龄对象加起来超过了S区50%。比如年龄1 + 年龄2 + 年龄3的对象大小总和，超过了S区的50%，此时就会把年龄3及以上的对象都放入老年代.

  。

动态年龄判断规则有个推论：如果S区中的同龄对象大小超过S区内存的一半，就要直接升入老年代.

  。

第三：新生代垃圾回收后，存活对象太多无法放入S区，直接进入老年代 。

其实上述条件中，第二个和第三个都是很关键的。如果新生代的S区内存过小，就会导致上述第二个第三个条件频繁发生。然后导致大量对象快速进入老年代，从而频繁触发老年代GC.

  。

二.老年代GC都很耗费时间 。

无论是CMS垃圾回收器还是G1垃圾回收器，老年代GC都很耗费时间。如CMS有初始标记->并发标记->重新标记->并发清理->碎片整理环节，这几个环节的过程非常的复杂，对于G1也同样如此.

  。

通常来说，老年代GC至少比新生代GC慢10倍以上。比如新生代GC每次耗费200ms其实对用户影响不大，但是老年代GC每次耗费2s就可能导致老年代GC时的用户请求卡顿2s，这时老年代GC对用户的影响就会很大.

  。

所以一旦JVM内存分配不合理，导致老年代频繁GC，就会影响系统性能。比如几分钟就有一次老年代GC，每次老年代GC时系统都停顿几秒，那用户可能就会发现他发起的请求也会每几分钟卡顿几秒.

  。

(6)JVM性能优化到底在优化什么 。

基于JVM运行的系统最大的问题其实就是：因为内存分配、参数设置不合理，导致对象频繁进入老年代。然后频繁触发老年代GC，导致系统每隔几分钟就要卡顿几秒钟。这就是所谓的JVM性能问题，也是JVM性能优化时需要优化的地方.

  。

2.什么是Young GC什么是Full GC 。

(1)Minor GC / Young GC 。

(2)Full GC / Old GC 。

(3)Full GC 。

(4)Major GC 。

(5)Mixed GC 。

  。

(1)Minor GC / Young GC 。

新生代也可以称为年轻代，这两个名词是等价的。当新生代的Eden内存区被占满后，就需要触发新生代GC(年轻代GC)。此时这个新生代GC就是所谓的Minor GC，也可以称为Young GC。所以Minor GC和Young GC这两个名词，就是专门针对新生代GC的.

  。

(2)Full GC / Old GC 。

老年代被占满后就会触发老年代的GC，也会把这种GC也称为Full GC，但有人会觉得老年代的GC不能叫Full GC。《深入理解Java虚拟机》中Full GC指收集整个Java堆和方法区的垃圾。所以所谓老年代GC，称Old GC可能会更加合适，字面意义上比较符合。但有时候如果把老年代GC称为Full GC，其实也是可以的。老年代GC，还有一种叫法是Major GC.

  。

(3)Full GC 。

Full GC指的是针对新生代、老年代、永久代的全体内存空间的垃圾回收。从字面意思上也可以理解，Full就是整体的意思。所以Full GC就是对JVM的一次整体的垃圾回收，把各区的垃圾都回收掉.

  。

(4)Major GC 。

Major GC其实一般用的比较少，它是一个非常容易混淆的概念。有些人把Major GC跟Old GC等价，认为它就是针对老年代的GC。也有人把Major GC和Full GC等价，认为它是针对JVM全部区域的GC.

  。

(5)Mixed GC 。

Mixed GC是G1中特有的概念，主要是指在G1中，一旦老年代占堆内存45%了，就要触发Mixed GC，此时年轻代和老年代都会进行回收.

  。

3.Young GC、Old GC和Full GC的发生情况 。

(1)名词解释 。

(2)Young GC的触发时机 。

(3)Old GC和Full GC的触发时机 。

(4)永久代填满了之后怎么办 。

  。

(1)名词解释 。

可以认为Young GC就是年轻代的GC，Old GC就是老年代的GC，Full GC是针对年轻代、老年代、永久代进行的整体的GC.

  。

Minor GC也可以称之为Young GC，Major GC也可以称之为Old GC，有的人也把Major GC和Full GC划等号，也有人把Full GC和Old GC划等号.

  。

这里用Young GC指代年轻代GC，用Old GC指代老年代GC，用Full GC指代年轻代、老年代、永久代共同的GC.

  。

(2)Young GC的触发时机 。

Young GC是在新生代Eden区域满了之后就会触发，采用复制算法来回收新生代垃圾.

  。

(3)Old GC和Full GC的触发时机 。

一.Old GC的触发时机 。

情况一：发生Young GC之前进行检查 。

如果老年代可用空间 < 新生代历次GC后入进老年代的对象的平均大小，说明本次YGC后升入老年代的对象大小，可能超过老年代当前可用空间。此时就要先触发一次Old GC给老年代腾出更多空间，然后再执行YGC.

  。

情况二：执行Young GC之后有一大批对象需要放入老年代 。

此时老年代已经没有足够的内存空间存放这些对象了，因此必须立即触发一次Old GC.

  。

情况三：老年代内存使用率已超过了92%，也要直接触发Old GC 。

当然这个比例是可以通过参数调整的.

  。

上述三个条件可以概括成一句话：由于老年代空间不够 + 没法放入更多对象，于是就要执行Old GC回收老年代垃圾。注意：执行Old GC时一般都会带上一次Young GC.

  。

二.Full GC的触发时机 。

在很多JVM实现里，其实达到上述几种条件时，触发的就是Full GC。Full GC会包含Young GC、Old GC和永久代(方法区/元数据区)的GC，也就是触发Full GC时，会回收新生代、老年代和永久代里面的垃圾对象.

  。

(4)永久代填满了之后怎么办 。

当存放类信息、常量池的永久代满了之后，就会触发一次Full GC。因为Full GC执行时会顺带把永久代中的垃圾给回收了，但是永久代中的垃圾一般是很少的。永久代里存放的都是一些类、常量池等，这些信息一般是不需要回收的。如果永久代真的满了，回收后发现没腾出更多空间，则只能抛出OOM.

  。

4.频繁YGC的案例(G1解决大内存YGC过慢) 。

(1)服务于百万级商家的BI系统是什么 。

(2)刚开始上线BI系统时的部署架构 。

(3)技术痛点：实时刷新报表+大数据量报表 。

(4)没什么大影响的频繁Young GC 。

(5)提升机器配置：运用大内存机器 。

(6)用G1来优化大内存机器的Young GC性能 。

(7)总结 。

  。

(1)服务于百万级商家的BI系统是什么 。

作为一个电商平台，可能会有数十万到百万的商家在平台上做生意。电商平台每天会产生大量数据，需要基于这些数据为商家提供数据报表。比如：每个商家每天有多少访客、有多少交易、付费转化率是多少.

  。

BI系统其实就是把商家日常经营的数据收集起来进行分析，然后提供各种数据报表给商家的一套系统.

  。

这样的一个BI系统，其运行逻辑如下:

首先电商平台会提供一个业务平台给商家进行日常使用交互。该业务平台会采集到商家的很多日常经营数据。然后根据这些日常经营数据，通过Hadoop、Spark等技术计算各种数据报表。这些数据报表会被放入存储到MySQL、Elastcisearch、HBase中。最后基于MySQL、HBase、ES中存储的数据报表，开发出一个BI系统。通过这个BI系统就能把各种存储好的数据展示给商家进行筛选和分析.

(2)刚开始上线BI系统时的部署架构 。

刚开始系统上线时，这个BI系统使用的商家是不多的，比如几千个商家。所以刚开始系统部署得非常简单，就是用几台机器来部署上述BI系统。机器都是普通的4核8G配置，在这个配置下，会给堆内存新生代分配1.5G内存，Eden区大概1G左右。如下图示:

(3)技术痛点：实时刷新报表+大数据量报表 。

刚开始在少数商家的情况下，这个系统是没多大问题的，运行非常良好。但使用系统的商家开始越来越多，商家的数量级达到几万时就有问题了.

  。

首先说明一下此类BI系统的特点，就是在BI系统中有一种实时数据报表，它支持前端页面运行一个JS脚本，该JS脚本每隔几秒就会自动发送请求到后台刷新一下数据。如下图示:

虽然只有几万商家使用该系统，但可能同时打开实时报表的商家有几千。每个商家打开报表后，前端都会每隔几秒发送请求到后台加载最新数据。于是部署BI系统的每台机器每秒请求就已达几百个，假设每秒500请求.

  。

然后每个请求会加载出一张报表所需要的大量数据，BI系统可能还要针对这些数据在内存中进行计算加工，才能返回。根据测算，每个请求大概会从MySQL中加载出100K的数据进行计算。因此每秒500个请求，就需要加载50M的数据到内存中进行计算。如下图示:

(4)没什么大影响的频繁Young GC 。

在上述系统运行模型下，由于每秒会加载50M的数据到Eden区中。所以只要200s就会填满Eden区，然后就会触发一次YGC。1G左右的Eden区进行YGC的速度也是比较快的，可能几十ms就搞定了。所以每200s频繁执行一次YGC其实对系统性能影响并不大，而且上述场景下，基本上每次YGC后存活对象可能会有几十M.

  。

因此可能会看到如下场景：BI系统每运行几分钟就会突然卡顿10ms，但几乎不影响用户和系统性能.

(5)提升机器配置：运用大内存机器 。

针对这样的一套BI系统：当越来越多商家使用，并发压力越来越大，甚至高峰期QPS达每秒10万。如果还用4核8G机器，则要部署上百台机器来抗每秒10万的并发压力.

  。

所以针对这种情况，假设决定通过提升机器配置去处理。那么由于BI系统非常吃内存，所以将机器配置全面提升到16核32G。这样每台机器可以抗每秒几千请求，此时只要部署二三十台机器即可.

  。

此时问题就来了：如果用大内存机器，则新生代内存至少会分配20G，Eden区也会占16G。由于每个请求加载100K数据，故每秒几千请求会加载几百M数据到内存。那么大概1分钟左右就会填满Eden区，需要执行YGC。此时YGC要回收那么大的内存，速度会慢很多，也许会导致系统卡顿个几百毫秒或者1秒.

  。

如果系统卡顿时间过长，必然会导致很多请求积压排队，严重时会导致线上系统时不时出现前端请求超时的问题.

  。

(6)用G1来优化大内存机器的Young GC性能 。

所以对这个系统的优化，就是采用G1来应对大内存下YGC过慢的问题。可以对G1设置一个预期的GC停顿时间，比如100ms。让G1保证每次Young GC时最多停顿100ms，避免影响终端用户的使用.

  。

此时效果是非常显著的。G1在每次YGC时会回收一部分Region，确保GC停顿时间在100ms内。这样也许YGC频率高一些，但由于每次停顿时间很小，对系统影响不大.

  。

(7)总结 。

通常来说，YGC即使发生比较频繁，其实对系统也造成不了太大影响。只有在机器内存特别大时，才要注意YGC可能会导致比较长时间的停顿。所以针对大内存机器通常建议采用G1垃圾回收器.

  。

5.频繁FGC的案例(YGC存活对象S区放不下) 。

(1)一个日处理上亿数据的计算系统 。

(2)这个系统多久会塞满新生代 。

(3)触发YGC时会有多少对象进入老年代 。

(4)系统运行多久老年代就会被填满 。

(5)这个系统运行多久，老年代会触发1次FGC 。

(6)该案例应该如何进行JVM优化 。

(7)如果该系统的工作负载再次扩大10倍 。

(8)使用大内存机器来优化上述场景 。

  。

(1)一个日处理上亿数据的计算系统 。

当时团队里自研的一个数据计算系统，日处理数据量在上亿的规模。这个系统会不停的从MySQL数据库以及其他数据源里提取大量的数据，然后加载到自己的JVM内存里来进行计算处理。如下图示:

这个数据计算系统会不停的通过SQL语句和其他方式，从各种数据存储中提取数据到内存中来进行计算，大致当时的生产负载是每分钟需要执行500次数据提取和计算的任务.

  。

由于这是一套分布式运行的系统，所以生产环境部署了多台机器。每台机器大概每分钟负责执行100次数据提取和计算的任务(15个线程)。每次会提取大概1万条数据到内存计算，平均每次计算大概耗费10秒。然后每台机器4核8G，新生代和老年代分别是1.5G和1.5G的内存空间。如下图示:

(2)这个系统多久会塞满新生代 。

现在明确了一些核心数据，那么该系统多久会塞满新生代的内存空间？既然每台机器上部署的该系统实例，每分钟会执行100次数据计算任务。每次1万条数据需要计算10秒时间，该台机器大概开启15个线程去执行.

  。

那么先来看看每次1万条数据大概会占用多大的内存空间。这里每条数据都是比较大的，每条数据大概包含20个字段。可认为平均每条数据的大小在1K左右，那么每次计算任务提取的1万条数据就对应了10M大小.

  。

所以如果新生代按照8:1:1的比例来分配Eden和两块Survivor的区域，那么Eden区就是1.2G，每块Survivor区在100M左右。如下图示:

由于每次执行一个计算任务，就要提取1万条数据到内存，每条数据1K。所以每次执行一个计算任务，JVM会在Eden区里分配10M的对象。那么由于一分钟需要执行大概100次计算任务，所以新生代里的Eden区，基本上1分钟左右就会被迅速填满.

  。

(3)触发YGC时会有多少对象进入老年代 。

假设新生代的Eden区在1分钟后都塞满对象了，在继续执行计算任务时，必然会导致需要进行YGC回收部分垃圾对象.

  。

一.在执行YGC前会先进行检查 。

首先会看老年代的可用内存空间是否大于新生代全部对象。此时老年代是空的，大概有1.5G的可用内存空间，而新生代的Eden区大概有1.2G对象.

于是会发现老年代的可用内存空间有1.5G，新生代的对象总共有1.2G。即使一次YGC过后，即时全部对象都存活，老年代也能放的下的。所以此时会直接执行YGC.

  。

二.执行YGC后，Eden区里有多少对象是存活的无法被垃圾回收的 。

由于新生代的Eden区在1分钟就塞满对象需要YGC了，而1分钟内会执行100次任务，每个计算任务处理1万条数据需要10秒钟.

  。

假设执行YGC时，有80个计算任务都执行结束了。但还有20个计算任务共计200M的数据还在计算中，那么此时就有200M的对象是存活的，不能被垃圾回收掉。所以总共有1G对象可以进行垃圾回收，200M对象存活无法被垃圾回收。如下图示:

三.此时执行一次YGC会回收1G对象，然后出现200M的存活对象 。

这200M的存活对象并不能放入S区，因为一块S区只有100M的大小。此时老年代会通过空间担保机制，让这200M的对象直接进入老年代中。于是需要占用老年代里的200M内存空间，然后对Eden区进行清空.

(4)系统运行多久老年代就会被填满 。

按照上述计算，每分钟都是一个轮回。大概算下来是每分钟都会把新生代的Eden区填满。然后触发一次YGC，接着大概会有200M左右的数据进入老年代.

  。

假设2分钟过去了，老年代已有400M内存被占用，只有1.1G内存可用。此时老年代的可用内存空间已经少于新生代的内存大小了。所以如果第3分钟运行完毕，又要进行YGC，会做什么检查呢？如下图示:

一.首先检查老年代的可用空间是否大于新生代全部对象 。

此时老年代可用空间1.1G，新生代对象有1.2G。如果这次YGC过后新生代里的对象全部都存活，那么老年代是放不下它们的.

  。

二.接着就得检查HandlePromotionFailure参数是否打开 。

如果"-XX:-HandlePromotionFailure"参数被打开了，一般都会打开，此时会进入下一个检查：老年代可用空间是否大于历次YGC过后进入老年代的对象的平均大小.

  。

前面已计算出大概每分钟会执行一次YGC，每次200M对象进入老年代。此时老年代可用1.1G，大于每次YGC进入老年代的对象平均大小200M。所以可推测本次YGC后大概率还是有200M对象进入老年代，1.1G足够。因此这时就可以放心执行一次YGC，然后又有200M对象进入老年代.

  。

三.转折点大概在运行了7分钟后 。

执行了7次YGC后，大概1.4G对象进入老年代，老年代剩余空间就不到100M，几乎满了。如下图示:

(5)这个系统运行多久，老年代会触发1次FGC 。

大概在第8分钟运行结束时，新生代又满了。执行YGC之前进行检查，发现老年代此时只有100M的可用内存空间，小于历次YGC后进入老年代的200M对象，于是就会直接触发一次FGC。FGC会把老年代的垃圾对象都给回收掉.

  。

假设此时老年代被占据的1.4G空间里，全部都是可以回收的对象，那么此时就会一次性把这些对象都给回收掉。如下图示:

然后执行完FGC后，还会继续执行YGC，又有200M对象进入老年代，之前的FGC就是为这次新生代YGC后要进入老年代的对象准备的。如下图示:

所以按照这个运行模型进行分析：平均八分钟会发生一次FGC，这个频率就很高了，而且每次FGC速度都是很慢的、性能很差.

  。

(6)该案例应该如何进行JVM优化 。

通过上述案例可以清楚看到：新生代和老年代应该如何配合使用，什么情况会触发Young GC和Full GC，什么情况会导致频繁Young GC和Full GC.

  。

如果要对这个系统进行优化：由于该系统是数据计算系统，每次YGC时都会有一批数据没计算完毕。所以按现有的内存模型，最大问题就是每次YGC后S区放不下存活对象.

  。

所以可以对生产系统进行调整：增加新生代的内存比例，3G堆内存的2G给新生代，1G给老年代。这样S区大概就是200M，每次刚好能放得下YGC过后存活的对象。如下图示:

只要每次YGC过后200M存活对象可以放进Survivor区域，那么等下次YGC时，这个S区的对象对应的计算任务早就结束可回收了。比如此时Eden区里1.6G空间被占满了，然后S1区里有200M上一轮YGC后存活的对象。如下图示:

此时执行YGC后：就会把Eden区里1.6G对象回收掉，S1区里的200M对象也会回收掉。然后Eden区里剩余的200M存活对象会放入S2区里，如下图示:

以此类推，基本就很少有对象进入老年代了，老年代的对象也不会太多。这样就把生产系统老年代FGC的频率从几分钟一次降低到几小时一次。大幅度提升了系统的性能，避免了频繁FGC对系统运行的影响.

  。

前面说过一个动态年龄判定升入老年代的规则：如果S区中的同龄对象大小超过S区内存的一半，就要直接升入老年代.

  。

所以这里的优化仅仅是做一个示例说明而已，实际S区200M还是不够。但表达的是要增加S区大小，让YGC后的对象进入S区，避免进入老年代.

  。

实际上为了避免由于动态年龄判定规则而把S区中的对象直接升入老年代，如果新生代内存有限，那么可以调整"-XX:SurvivorRatio=8"参数。比如降低Eden区的比例(默认80%)，给两块S区更多的内存空间。让每次YGC后的对象进入S区，避免动态年龄规则把它们升入老年代.

  。

(7)如果该系统的工作负载扩大10倍 。

一段时间过后，该系统工作负载扩大10倍，每日需处理10亿数据的计算。根据上图，此时会导致每秒要加载100M的数据到内存里。对于1.6G的Eden区而言，10多秒就会迅速塞满，此时就会触发YGC.

  。

但由于每次加载一批数据到内存里，一般要处理10秒以上才可以计算完毕，而在计算完毕之前这些数据都是不能被回收的.

  。

所以如果10多秒就触发一次YGC，导致的后果就是：可能可以回收掉的垃圾也就几百M，有1G的对象可能都是无法回收的。于是就会导致每隔10多秒，就有1G对象进入老年代，而老年代也就1G。即使勉强能放下，那么10多秒过后下一次YGC又会放1G对象到老年代。此时必然会提前触发FGC去回收老年代里的1G对象，然后再把这次YGC后存活的1G对象放入老年代.

  。

这就是当时遇到的生产场景：一台4核8G的机器，每分钟要触发几次FGC，对系统性能造成巨大影响.

  。

(8)使用大内存机器来优化上述场景 。

针对负载扩大10倍导致的问题，因为计算类的系统非常吃内存，所以将数据计算系统的每台机器都更换成了16核32G的高配置机器。这样Eden的空间就会扩大10倍，比如有16G，Survivor区就会有2G.

  。

由于每秒会加载100M数据到内存计算，所以2分钟才会触发一次YGC。因为降低了YGC的频率，所以每次YGC时存活的对象大概也就几百M。因S区有2G，故每次YGC后的存活对象可轻松放入S区，不会进老年代。这就完美地通过提升机器配置的方式，解决了频繁YGC和FGC的问题.

  。

那么针对大内存机器，此时是否需要用G1来减少每次YGC的停顿时间？不需要，因为数据计算系统是一个后台自动计算系统，它不面向用户。所以哪怕每隔2分钟一次YGC，一次停顿几秒钟，也没任何影响。因此如果大内存机器不是面向用户的，其实也可以不用G1垃圾回收器.

  。

6.问题汇总 。

问题一:

G1和ParNew + CMS调优原则都是尽可能YGC，不做老年代GC。G1相对而言更加智能，这也意味着JVM会用更多资源去判断每个Region的使用情况.

  。

ParNew + CMS则更加纯粹和直接。虽然G1不会产生碎片，但由于Region存活率大于85%会不清理，所以G1会导致内存没有充分释放.

  。

因此，对于CPU性能高的 + 内存容量大的 + 用户响应敏感的系统推荐使用G1，对于内存小的 + CPU性能比较低的系统使用ParNew + CMS会更合适.

  。

问题二:

为什么说G1适合大堆的情况?

  。

答：假设有32G内存。如果用ParNew+CMS，必须内存填满了才会触发GC。此时进行新生代GC就会回收几十G垃圾，那么速度就会很慢。从而可能导致系统停顿时间多达几秒甚至更高都有可能。但是用了G1后，它会频繁地回收Region，且每次只回收一部分Region。从而保证停机时间不会太长，所以G1其实更加适合大内存的机器.

  。

问题三:

一.YGC和OGC一样都是追踪GC Roots，为什么后者的追踪更慢呢?

二.从GC Roots追踪，指的是GC线程会从扫描栈的局部变量开始吗?

  。

答：一.老年代GC，从GC Roots开始追踪。但老年代的存活对象多，所以追踪速度慢。新生代存活对象少，所以追踪速度快。二.两种典型的GC Roots：方法里的局部变量、类的静态变量，初始标记的时候会从这两个地方开始追踪扫描.

  。

问题四:

系统创建的对象被分配到Java堆内存中，要计算对象内所占的内存大小，就要计算对象的每个部分所占内存大小。Java对象包括：对象头、实例数据以及对象填充。对象头包括对象的基本信息以及Class的指针类等相关信息占用64bit。实例数据包括八种数据基本类型以及引用类型。将所用的进行全部相加，并且使用8的最低倍数进行对象填充。最后得出的结果就是所占用的内存空间bit.

  。

问题五:

G1回收器的垃圾回收原理总结如下:

一.如果新生代未达60%，老年代未达45%，系统照常运行，不会触发回收 。

二.如果新生代达60%，此后如果有新对象生成放入新生代，则会触发YGC 。

三.如果老年代达到45%，则触发混合回收 。

  。

混合回收时:

一.首先通过GC Roots初始标记存活对象，此过程会STW不过很快 。

二.然后并发标记，用户线程和标记线程并行 。

三.接着最终标记，会STW，标记并发标记过程中可能新产生的垃圾对象 。

四.最后混合回收，采用复制算法，不会产生垃圾碎片，不用整理碎片 。

  。

G1会按照给定的时间去STW并回收，争取回收性价比高的Region。默认下，如果回收次数少于8次，则再次混合回收。不过在回收过程中，如果发现空闲Region大小达到堆5%，会提前结束。如果Region回收失败，则会转换采用Serial Old回收器.

  。

问题六:

长生命周期的对象有哪些?

  。

答：长生命周期的对象有:

一.Spring的Bean 。

二.线程池的核心线程及其引用的对象，其中包括ThreadLocal引用的对象 。

三.Tomcat组件：Connector和Container(如Filter，Servlet，Listener) 。

四.Classloader、Class对象也是长生命周期 。

五.各类池化技术，比如线程池，连接池等 。

  。

最后此篇关于JVM实战—6.频繁YGC和频繁FGC的后果的文章就讲到这里了,如果你想了解更多关于JVM实战—6.频繁YGC和频繁FGC的后果的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。