记一次 Jvm 参数调优实战

案例一

      public class test1 { private static final int _1MB = 1024 * 1024;   public static void main(String[] args) throws IOException, InterruptedException { System.out.println("My Process Id is:"+getProcessID()); Thread.sleep(10000); byte[] all1 = new byte[ 2 * _1MB]; byte[] all2 = new byte[ 2 * _1MB]; Thread.sleep(2000); byte[] all3 = new byte[ 2 * _1MB]; byte[] all4 = new byte[ 7 * _1MB]; System.in.read(); } public static int getProcessID() { RuntimeMXBean runtimeMXBean = ManagementFactory.getRuntimeMXBean(); return Integer.valueOf(runtimeMXBean.getName().split("@")[0]) .intValue(); } } 复制代码      

注：这里getProcessId的作用是拿到进程号

jvm参数

      -Xmx20m // 设置最大堆大小 -Xms20m // 设置最小堆大小，一般和-Xmx一致 -Xmn10m // 设置新生代大小 -XX:+UseParNewGC //表示新生代使用ParNewGc -XX:+UseConcMarkSweepGC // 表示老年代使用CMS -XX:+UseCMSInitiatingOccupancyOnly //表示CMS不基于运行时收集数据来进行GC控制 -XX:CMSInitiatingOccupancyFraction=75 //而表示当老年代使用率到达阈值75%时触发 复制代码      

我们这么设置JVM参数，就可以看出一些基本设置：

• 年轻代 10M

• 老年代 10M

• eden:s0:s1 = 8:1:1

• 新生代使用ParNewGc

• 老年代使用CMS，并只有当老年代使用率超过75的时候触发FullGC

我们先简单看一下这么设置有什么问题：

代码里先创建了 2M的对象，直接放入eden区，再创建了2M的对象，同样也放入eden区，此时eden 有4M的对象，再创建了2M的对象，eden有4M，可以放更多，这2M也放进了eden，最后创建了7M对象，eden区存不下，所以会触发一次young gc，但是剩下的s0，s1已经放不下，所以放入老年代，此时 eden有7M对象，老年代有6M对象，此时年轻代和老年代都有剩下的空间，不会触发GC，但，真的是这样吗？

我们实战看看：，在程序开始时，记录下输出的pid，然后 在程序运行的饿时候在cmd使用 jstat -gcutil pid 1000 ,每一秒输出一次gc信息，看看结果是什么，先在代码上每一处加上sleep为了方便观察

 

 

第一个绿线，是第一个2M对象生成，此时eden区使用了63%，6.3M的空间

第二个绿线，是第二个2M对象生成，此时eden区使用了88%，8.8M空间

第三个绿线，是第三个2M对象生成，此时eden区并不足够承载这个2M对象，

此时进行young GC，如图YGC被触发一次，但是现存的4MB对象均不能被回收，且大于S0、S1的空间，所以直接进入老年代，此时老年代有4M的空间，正好是那两个2M的对象，此时Eden区已经可以存放2M，此时eden去和s0一起young gc 可以放入s1的对象即1M左右的零碎对象放入了S1，然后s1、s0名称互换 。

而且，第一次young gc后，消失了部分空间，这即是 “垃圾""， 被回收掉了，但是为什么Metespace区容量暴增呢？

第四个红线，是第四个7M对象生成，eden区并不能存放这个7M的大对象，则需要进行一次younggc，s1中的100%的1M的对象被垃圾回收部分垃圾并放到了s0区，同样此时eden区的2.5M有一个2M的对象，此时没有办法进入s0 s1，所以只能进入老年代，此时老年代占用70%，而eden占用90%，并不具备full gc触发条件，当时full GC被触发，

且每隔两秒被触发一次？这是为什么？

我们再这个jstat上已经无法得出更重要的信息，我们打印GC日志看看，

在启动参数上加上

      -XX:+PrintGCDetails // 打印详细日志 -XX:+PrintHeapAtGC // 在GC前后打印堆信息 -XX:+PrintGCDateStamps // 打印时间 复制代码      

我们启动后，看看日志输出：

 

 

很容易发现，在第三个2MB分配时，进行了一次GC，在GC前堆的信息为：

eden：88%， s0 0%，s1 0% CMS 区0%，元空间区0%，类空间 0%

此时日志里写到 Allocation Failure ，即空间分配失败，然后后面PerNew的空间由 7261k-》1023K，即进行一次young GC，此时年轻代空间总大小为9216K，为啥不是10240k?因为这里算得空间是eden+s1

然后看gc后的堆的空间信息：eden为0，即所有的对象都被移走了，移到哪了？4M的大对象移到了堆，剩下的进行垃圾回收只剩下1023k移入到了from也就是s1区

此时老年代有4117k，即4M的大对象

然后GC后就是分配刚刚的2MB的对象到eden，如下图刚开始就有26%的used，就是这个2MB的对象

然后后面就是分配一个7M的大对象

 

 

在分配7MB大对象时，进行了一次young GC，同样看GC日志 ，perNew由3217K-》102K 然后看GC后的堆空间情况：eden：0，s1：9%，CMS区 7219k，72%

• 到这里就和上面的jstat的信息保持一致，那么主要关键点在下面

 

 

剩下的未截出的都是完全重复的信息

这些记录里记录了什么？

首先是CMS初始标记CMS Initial Mark，此时STW

然后进入并发标记CMS-concurrent-mark-start

并在并发标记中执行并发预清理CMS-concurrent-preclean-start，由于此时并没有对象能被清理，所以此处无效，也没有消耗时间

并发预清理主要做两件事：

处理新生代已经发现的引用

如果老年代中有对象内部引用发生变化，会把所在的Card标记为Dirty

在执行预清理过程中，有个可中断的预清理CMS-concurrent-abortable-preclean-start，这里主要做两件事：

处理 From 和 To 区的对象，标记可达的老年代对象

扫描处理Dirty Card中的对象

最后执行 重新标记Final Remark，STW

然而后面就没有数据了，后面又是重复的进行CMS的扫描，没有执行清理，同样也没有执行Full GC

那么上面的Full GC又是怎么来的呢？

根据资料显示：这是CMS的一个并行收集阶段，只有到达阈值 （75）才进行清除

之前的标记信息都是并行收集阶段，走这一步在JVM监控中识别成了一次Full GC，实则并不是！

破案了，所以这并不是2秒一次Full GC，而是2秒一次CMS的并行搜集！

案例二

同样是上面的例子，例子来源上说当不用CMS时，不会触发，原因是什么？（88当然是没有并行收集这一阶段，直接没有Full gc信息**）

案例三

同样是上面例子，当接着再次生成一个8M的对象，会发生什么？

直接OOM，因为在生成之前，eden最大也8M，存不下这个8M，然后老年代也存不下，直接抛出错误

经测试，大于等于4M的大对象在此时创建，均会OOM

此时为：eden区已经被使用了89%，老年代也被使用了 6817k，完全不足以支撑下个对象，所以OOM

那么这个最大4M是怎么得来的？此时eden只有一个7M的大对象，此时这个7M的大对象并不能放入老年代，所以此时放入堆中的对象只有：小于eden区的剩余空间，1M，或者小于老年代的剩余空间，即4M，所以这个4，就是这么来的

还是看看GC日志把

 

 

当分配第五个7M的前后，为什么eden区突然有了89%的占用率？其实这就是上一个GC后释放了空间，释放的空间就在GC后显示，然后才是这个第四个7M分配的空间，所以这个89%，就是第4个7M分配的空间

 

 

在分配第五个7M的时候，eden区放不下，所以先进行一次young gc，但是此时年轻代存的都是存活的大对象，无法被回收，所以这个年轻代GC并没有回收任何一点垃圾 然后后面再回进行一次GC，即FullGC

 

 

这个FullGC一共回收了俩地方，一个CMS，一个matespace（后面没截出来 此时CMS经过Full GC后仍然有6781K，而matespace就一点没小，所以此时老年代无法分配空间， 这里不youngGC是因为前面已经YoungGC过了， 此时年轻代老年代都不足以分配空间给新对象，所以OOM

案例四

还是上面的例子，如果有两种情况，一种是第4个7M接下来分配一个小于1M的对象，这个对象会被分配到哪？如果是大于2M小于4M呢？

先来分配一个1M的对象（小于当前eden区的剩余空间

 

 

此时eden只有11%的剩余 1.1M，可以承载1M的对象，但是超过了阈值（95）触发young gc

young gc过后，将其放入eden，加上一些空间碎片，此时eden已经100%，再次歘young gc，

此时eden有俩对象，一个7M，一个1M，就只能将1M的对象放入老年代，此时eden占用了90%的空间

我们再来分配一个3M的对象，此时eden同样无法接受3M对象，先执行一次young gc，然后仍然无法存储，但是老年代空间够，所以直接移到老年代去，此时老年代有90%的占用率，但是后面为什么没有触发Ful gc？（这里省略了图）

看完三件事❤️

如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：

1. 点赞，转发，有你们的 『点赞和评论』，才是我创造的动力。

2. 关注公众号 『 java烂猪皮 』，不定期分享原创知识。

3. 同时可以期待后续文章ing

   原文地址：https://www.cnblogs.com/AIPAOJIAO/p/13896361.html

   版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [e-mail] 举报，一经查实，本站将立刻删除。