JVM 篇之 牛刀小试_-xms1g -xmx2g -xss256k -xx:maxmetaspacesize=512m -

前言

---

很久没有写博客了，沉寂了一段时间，那是因为我在闭关啃书，哈哈。JVM作为高级开发所需要具备的能力，在以往面试的时候都会遇到，让我印象很深刻的，就是面试欢聚的shopline，好家伙，面了两次，每次都是同一个人，然后每次都在JVM上跪了，然后面试官跟我说你回去看下周志明的《深入理解java虚拟机》。

志明，我有个同事也叫志明，是位运维同学。我也看过《志明与春娇》，现在志明有了，春娇在哪里，哈哈~

开个玩笑哈，那么这段时间我就计划将它读一读，然后上上手

JVM 参数

---

-Xms1g -Xmx1g -Xmn500m

大家知道什么意思吧，就是堆默认1g，最大1g，为了避免扩容的时候进行内存复制、迁移，导致效率降低。然后是年轻代 设置为500m，我们用的是java11，默认采用G1 垃圾回收器

JVM 监控命令

---

jps

查看进程，我们需要知道当前应用跑在哪个进程id下面

jstat

查看堆的情况，jstat -gcutil 可以查看gc情况的统计，会打印ygc、fgc、总gc的时间

jmap

导出堆的数据到文件hprof，这个方便导出快照进行查看当前运行情况，包括oom异常处理

jstack

查看当前堆内的线程在干哈，可以用于死锁的排查，他们在等待什么锁

JVM 监控软件+实战

---

MAT

它可以在线查看进程堆数据，也可以你自己jmap导出数据进去分析，这个是我连上本地应用之后的效果。

从圆形展示图来看，占比最大的居然是mybatis 这家伙，一下子占了5M，然后我们可以进去看下，它为啥占比那么高

好家伙，它会比所有mapper、sql，参数进行保存起来，方便你执行的时候，往里头塞数据，然后拼接成sql执行。

今天我去问了一个在深圳电商巨头的一个同学，他们公司wiki也有这么一个案例，mybatis里面少用foreach，其他也可以理解，当你循环越多的时候，跟java对象一样，里头的属性也会蹭蹭往上加。

jconsole

它可以监控堆内内存的情况，线程的情况，加载类数量。

基于上面MAT给出的信息，mybatis里头配置会有5M以上的对象，意味着是个大对象，在分代回收的机制下，年轻代会采用复制-清理算法来清理，一个比较大Eden，2个Survivor，这样的好处是快捷，我只需要把跟GC ROOT有关联的对象标记，然后复制到另一块，然后直接把之前那一块内存清理掉即可。当超过15次gc，对象还存活的话，就会放到老年代。

如果这5M在年轻代一直这么复制，那么会消耗很多效率，所以我们将大的对象直接在老年代创建，避免不断的复制带来的gc时间拉长。

效果

---

优化前

优化后

加多-XX:PretenureSizeThreshold=3145728 参数，就是如果超过3M的对象会直接在老年代创建

对比

优化前，gc主要在年轻代，YGC在0.210秒；优化后，YGC 在0.110秒，可以看到优化的效果还是很明显的。当然前者随着YGC的次数，gc时间一直在递增。后者老年代也发生了3次gc，因为大对象是在老年代创建的，优化前的老年代一直维持10M，优化后从40M直接突破70M，促发GC。

我们为什么要优化GC呢？

---

那是因为很多垃圾回收器在执行垃圾回收的时候，需要停止用户进程，避免迁移内存以及清空内存对数据的影响，所以gc的时间还有频率都是我们需要关注的