Advanced master JVM novice a road [z]

https://mp.weixin.qq.com/s/qD1LFmsOiqZHD8iZX97OfA?

 

Symptom

Code is as follows, using ParNew + Serial Old collector when used in combination with ParNew + CMS collector combination, the results Why so much difference?

1. private static final int _1MB = 1024 * 1024;

2.  

3.    public static void main(String[] args) throws Exception {

4.        byte[] all1 = new byte[2 * _1MB];

5.        byte[] all2 = new byte[2 * _1MB];

6.        byte[] all3 = new byte[2 * _1MB];

7.        byte[] all4 = new byte[7 * _1MB];

8.        System.in.read();

9.    }

jvm parameters as follows:

1. -Xmx20m

2. -Xms20m

3. -Xmn10m

4. -XX:+UseParNewGC

5. -XX:+UseConcMarkSweepGC

6. -XX:+UseCMSInitiatingOccupancyOnly

7. -XX:CMSInitiatingOccupancyFraction=75

By jstat command, view the results as follows:

About jstat command details can refer to: https: //docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html

jvm parameters adjusted as follows:

1. -Xmx20m

2. -Xms20m

3. -Xmn10m

4. -XX:+UseParNewGC

By jstat command, view the results as follows:

Explanation

The above title is just an entry point just hope that through some of the basics of an entry point for the jvm just good note, the way to answer under the above phenomenon.

Memory-related brief description

FIG parameters: -Xms set the minimum heap space (-Xmx and as generally recommended). -Xmx sets the maximum heap size. -Xmn set the size of the new generation. -XX: MetaspaceSize metadata set the minimum space. -XX: MaxMetaspaceSize set the maximum size of the metadata space. -Xss set the stack size for each thread (There is a story here, three years ago with regular expressions, regular expressions follow-empty talk).

Note: tenured space to use subtraction to understand that the young generation heap size minus the size of it.

Here, following several parameters should understand.

1. -Xmx20m

2. -Xms20m

3. -Xmn10m

Note: Parameter -XX: SurvivorRatio used to indicate the ratio between s0, s1, eden, default -XX: SurvivorRatio = 8 expressed s0: s1: eden = 1: 1: 8.

It concluded: eden = 8M, s0 = 1M, s1 = 1M, tenured = 10M.

JVM garbage payback combination

There is also a problem to be solved, jvm garbage collector aspects, the following chart, I am my JVM advanced novice master of the road eight (some details) , which, when vaguely remember that this figure should be sent to me by Allen .

由于那个时候jdk9还没有出来，可以去看看我的JVM菜鸟进阶高手之路十二（jdk9、JVM方面变化， 蹭热度），虽然有些有些稍微去掉了，但是整体的组合还是影响不大。

由于上面的2个jvm参数都是基于分代收集算法的（先不考虑G1）

• 依据对象的存活周期进行分为新生代，老年代。

• 根据不同代的特点，选取合适的收集算法

• 新生代，适合复制算法

• 老年代，适合标记清理或者标记压缩

复制算法

• 将原有的内存空间分为两块，每次只使用其中一块，在垃圾回收时，将正在使用的内存中的存活对象复制到未使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。

• 不适用于存活对象较多的场合 如老年代。（年轻代对象基本都是朝生夕灭所以特别适合，由于那样的话复制就少，如果类似老年代有大量存活对象，那么进行复制算法性能就不是特别好了）

备注：使用复制算法的优点：每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况了，使用复制算法的缺点：对空间有一定浪费，所以复制空间一般不会特别大。

标记清除标记-清除算法将垃圾回收分为两个阶段：标记阶段和清除阶段。在标记阶段，首先先找出根对象，标记所有从根节点开始的可达对象。因此，未被标记的对象就是未被引用的垃圾对象。然后，在清除阶段，清除所有未被标记的对象。

备注：java根对象：

• 虚拟机栈中引用的对象。

• 方法区中类静态属性实体引用的对象。

• 方法区中常量引用的对象。

• 本地方法栈中JNI引用的对象。

• 等等。

  标记清除算法缺点：标记清除会产生不连续的内存碎片，如果空间内存碎片过多会导致，当程序在运行过程中需要分配空间时找不到足够的连续空间而不得不提前触发一次垃圾收集动作（根据算法不一样效果也不一样）。

标记压缩标记-压缩算法适合用于存活对象较多的场合，如老年代。它在标记-清除算法的基础上做了一些优化。和标记-清除算法一样，标记-压缩算法也首先需要从根节点开始，对所有可达对象做一次标记。但之后，它并不简单的清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。

备注：这样带来的好处就是不会参数内存碎片问题了。

上面已经说明了这么多了，我们可以继续说明上题中JVM的其他参数了。

1. -XX:+UseParNewGC

2. -XX:+UseConcMarkSweepGC

-XX:+UseParNewGC 表示新生代使用ParNew并行收集器，-XX:+UseConcMarkSweepGC 表示老年代使用CMS回收器（CMS收集器是基于“标记-清除”算法实现的，特别提醒由于CMS是标记清除算法实现的所以是存在碎片问题的）。可以去看看我的JVM菜鸟进阶高手之路六（JVM每隔一小时执行一次Full GC）、以及JVM菜鸟进阶高手之路七（tomcat调优以及tomcat7、8性能对比）图片就取的这两篇里面的。

备注：通过jstat -gcutil pid 查看的FGC这列的时候，CMS gc通常都是+2一次的，由于CMS-initial-mark和CMS-remark会stop-the-world。

所以看到这个图的FGC应该没有什么问题了吧。

1. -XX:+UseCMSInitiatingOccupancyOnly

2. -XX:CMSInitiatingOccupancyFraction=75

还有这2个参数关于cms的，-XX:+UseCMSInitiatingOccupancyOnly表示JVM不基于运行时收集的数据来启动CMS垃圾收集周期通过CMSInitiatingOccupancyFraction的值进行每一次CMS收集，-XX:CMSInitiatingOccupancyFraction=75 表示当老年代的使用率达到阈值75%时会触发CMS GC。

备注：jstat -gcutil可以看出上图的老年代的使用率才60.02%

还有最后一个参数解释:

1. -XX:+UseParNewGC

-XX:+UseParNewGC 表示新生代使用ParNew并行收集器，那么老年代呢？ 可以让同样参数修改代码执行一次old gc即可看日志有类似[Tenured:说明老年代使用的是Serial Old

备注：Serial Old使用的是标记压缩算法。

解题

1. private static final int _1MB = 1024 * 1024;

2.  

3.    public static void main(String[] args) throws Exception {

4.        byte[] all1 = new byte[2 * _1MB];

5.        byte[] all2 = new byte[2 * _1MB];

6.        byte[] all3 = new byte[2 * _1MB];

7.        byte[] all4 = new byte[7 * _1MB];

8.        System.in.read();

9.    }

说明：最后System.in.read();这句可以忽略，只是为了让程序阻塞在那里，不结束，这样好看日志，好看现象而已。

聪明如你一下子应该可以看到问题本质:同一份代码，jvm参数堆设置啥的都一样，年轻代gc参数也一样，唯一不同的就在于老年代gc使用上面，而jstat -gcutil图表中FGC没变的应该是正常结果，变了的CMS那个就是意外结果，所以关键点就在CMS上面了。

先来说说all1 、all12、all3、对象实例化开辟空间之后，eden空间都够，他们都在eden空间中，当all4过来的时候，eden空间不够了，需要执行ygc了。 下面有2个问题需要说明，1、如果s0能存的下，可以看看JVM菜鸟进阶高手之路三：MaxTenuringThreshold新生代的对象正常情况下最多经过多少次YGC的过程会晋升到老生代（CMS情况下默认为6），说到这里可能还需要提一个参数：-XX:TargetSurvivorRatio，可以参考飞哥的：JVM Survivor行为一探究竟（http://www.jianshu.com/p/f91fde4628a5） 2、如果s0存不下，就是我们这里的情况（由于我们这里s0就是1M而已）所以直接进入到old空间了，所以可以看出来jstat -gcutil 里面的老年代的比例都是60%几了吧。 ygc执行完成之后，all4就还可以在eden分配（空间够），所以可以看出来jstat -gcutil 里面的eden的比例都是89%几了吧

备注：-XX:PretenureSizeThreshold参数来设置多大的对象直接进入老年代（这个参数其实只对串行回收器和ParNew有效，对ParallelGC无效）。

如果是-Xmx20m -Xms20m -Xmn10m -XX:+UseParNewGC 这套参数，那么结果就是如图可以解释了，并且每个参数比例啥的都可以理解了。

下面来好好解释下这个现象：聪明如你一下子应该可以看到一个问题，那么就是时间间隔是每隔2s执行一次，没错就是2s执行一次。需要说道-XX:CMSWaitDuration(Time in milliseconds that CMS thread waits for young GC)默认值是2s，我们修改为-XX:CMSWaitDuration=5000看看效果：看到了吧，修改为5s就是5s执行一次变化了。那么至于为什么会执行呢？？

本题就是当前新生代的对象是否能够全部顺利的晋升到老年代，如果不能，会触发CMS GC。