性能文章>JVM菜鸟进阶高手之路十四:分析篇>

JVM菜鸟进阶高手之路十四:分析篇原创

1年前
711222

回顾

  • private static final int _1MB = 1024 * 1024;
  •  
  •    public static void main(String[] args) throws Exception {
  •        byte[] all1 = new byte[2 * _1MB];
  •        byte[] all2 = new byte[2 * _1MB];
  •        byte[] all3 = new byte[2 * _1MB];
  •        byte[] all4 = new byte[7 * _1MB];
  •        System.in.read();
  •    }
  •  

jvm参数配置如下:

  • -Xmx20m
  • -Xms20m
  • -Xmn10m
  • -XX:+UseParNewGC
  • -XX:+UseConcMarkSweepGC
  • -XX:+UseCMSInitiatingOccupancyOnly
  • -XX:CMSInitiatingOccupancyFraction=75
  •  

通过jstat命令,查看结果如下:

image.png

jvm参数调整如下:

  • -Xmx20m
  • -Xms20m
  • -Xmn10m
  • -XX:+UseParNewGC
  •  

通过jstat命令,查看结果如下:

image.png

说明

上面的题目仅仅是一个切入点而已,希望通过一个切入点把jvm的一些基础知识刚刚好说明下,顺便解答下上面的现象。

内存相关简单说明

image.png

图中参数:
-Xms设置最小堆空间大小(一般建议和-Xmx一样)。
-Xmx设置最大堆空间大小。
-Xmn设置新生代大小。
-XX:MetaspaceSize设置最小元数据空间大小。
-XX:MaxMetaspaceSize设置最大元数据空间大小。
-Xss设置每个线程的堆栈大小(这里有个故事,3年前用正则表达式,后续有空正则表达式再说)。

备注:tenured空间就用减法操作即可明白,堆空间大小减去年轻代大小就可以了。

说到这里,下面这个几个参数应该明白了。

-Xmx20m
-Xms20m
-Xmn10m

备注:参数-XX:SurvivorRatio用来表示s0、s1、eden之间的比例,默认情况下-XX:SurvivorRatio=8表示 s0:s1:eden=1:1:8。

得出结论:eden=8M,s0=1M,s1=1M,tenured=10M

JVM垃圾回收期组合

还有一个问题需要解决,jvm垃圾回收器方面,下面这个图,我是我的JVM菜鸟进阶高手之路八(一些细节),里面的,当时依稀记得这个图应该是飞哥发给我的。

image.png

由于那个时候jdk9还没有出来,虽然有些有些稍微去掉了,但是整体的组合还是影响不大。

image.png

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

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

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

  • 新生代,适合复制算法

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

复制算法

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

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

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

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

备注:java根对象:
虚拟机栈中引用的对象。
方法区中类静态属性实体引用的对象。
方法区中常量引用的对象。
本地方法栈中JNI引用的对象。
等等。
标记清除算法缺点:标记清除会产生不连续的内存碎片,如果空间内存碎片过多会导致,当程序在运行过程中需要分配空间时找不到足够的连续空间而不得不提前触发一次垃圾收集动作(根据算法不一样效果也不一样)。

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

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

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

  • -XX:+UseParNewGC
  • -XX:+UseConcMarkSweepGC
  •  

-XX:+UseParNewGC 表示新生代使用ParNew并行收集器,-XX:+UseConcMarkSweepGC 表示老年代使用CMS回收器(CMS收集器是基于“标记-清除”算法实现的,特别提醒由于CMS是标记清除算法实现的所以是存在碎片问题的)。

image.png

可以去看看我的JVM菜鸟进阶高手之路六(JVM每隔一小时执行一次Full GC)以及JVM菜鸟进阶高手之路七(tomcat调优以及tomcat7、8性能对比)图片就取的这两篇里面的。

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

image.png

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

  • -XX:+UseCMSInitiatingOccupancyOnly
  • -XX:CMSInitiatingOccupancyFraction=75
  •  

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

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

还有最后一个参数解释:

  • -XX:+UseParNewGC
  •  

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

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

解题

  • private static final int _1MB = 1024 * 1024;
  •  
  •    public static void main(String[] args) throws Exception {
  •        byte[] all1 = new byte[2 * _1MB];
  •        byte[] all2 = new byte[2 * _1MB];
  •        byte[] all3 = new byte[2 * _1MB];
  •        byte[] all4 = new byte[7 * _1MB];
  •        System.in.read();
  •    }
  •  

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

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

先来说说all1 、all12、all3、对象实例化开辟空间之后,eden空间都够,他们都在eden空间中,当all4过来的时候,eden空间不够了,需要执行ygc了。
下面有2个问题需要说明,1、如果s0能存的下,新生代的对象正常情况下最多经过多少次YGC的过程会晋升到老生代(CMS情况下默认为6),说到这里可能还需要提一个参数:-XX:TargetSurvivorRatio 2、如果s0存不下,就是我们这里的情况(由于我们这里s0就是1M而已)所以直接进入到old空间了,所以可以看出来jstat -gcutil 里面的老年代的比例都是60%几了吧
ygc执行完成之后,all4就还可以在eden分配(空间够),所以可以看出来jstat -gcutil 里面的eden的比例都是89%几了吧

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

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

image.png

下面来好好解释下这个现象:

image.png

聪明如你一下子应该可以看到一个问题,那么就是时间间隔是每隔2s执行一次,没错就是2s执行一次。需要说道-XX:CMSWaitDuration(Time in milliseconds that CMS thread waits for young GC)默认值是2s,我们修改为-XX:CMSWaitDuration=5000看看效果:

image.png

看到了吧,修改为5s就是5s执行一次变化了。那么至于为什么会执行呢??

image.png

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

分类:标签:
请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得