JVM实践（三）JVM调优案例

JVM实践（三）JVM调优案例

大部分的JVM调优，目的是降低GC次数，减少GC时间（STW耗时占大部分）。

从原因分析上

FULL GC频率高。正常10天半个月可能FULL GC一次，如果一天两三次就不正常了。

可能的原因：

   （1）内存泄漏，属于代码问题。

首先分析大对象，找到它，修复它，可能是代码上的缺陷，又或者是程序设计上漏洞。

   （2）元空间（metaspace，Java8后才有，以前是“永久代”）超了。项目代码量很大，类的基本信息（或者说静态数据）撑爆了元空间，触发了GC。

java -XX:+PrintFlagsInitial|grep MetaspaceSize 查看元空间初始值

修改默认值16m--->32m

-XX:MetaspaceSize=32m

具体案例分析

     其实到现在，是不是觉得还是手足无措，第一次吃饭，不知道怎么吃，不知道饭是怎么到肚子里的。不知道用碗盛饭，不知道用筷子夹菜，不知道用勺子舀汤。想知道怎么做吗？ 别问我，我也不知道，睡觉去。

案例1：我可以想象一下，假设你系统运行很慢——堆内存不足

首先，登录linux服务器，输入命令jps，找到java的进程号。

然后，看一下性能情况，也就是GC情况，输入命令：jstat -gc  -t  [进程号] 1s 5

1）.有可能你看到了GC次数多次。

那么，你可以看下堆内存分配情况：jmap -heap [进程号]

如果最大堆内存很小，就调大一下比如：512m-->4096m。

案例2：系统启动很慢——元空间不足

同样，jstat分析一下FULL GC情况，如果发现，唉，在启动的时候居然还FULL GC了一两次，那一般就是你的元空间不足啦。

-XX:MetaspaceSize=32m        16m-->32m

案例3：同样系统运行慢——代码内存泄漏

开头已经说过了，找到可能出现在老年代的大对象，这种啃老族应该找出来消灭它。那怎么操作呢？

首先，必须的两步肯定是 看进程号，看jstat。确认FULL GC次数多，然后再用jmap查看堆内存分配，那这种情况肯定是老年代存活了很多大对象了。看下图中那个used使用量，如果大于0肯定是存活着对象了。

接着，分析堆内存。有两种方式可以跟踪：

1.实时：jmap -dump:format=b,file=e:\a\heap.hprof [进程号]  实时查看jvm内存信息。

2.溢出跟踪：jvm启动参数中添加  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=e:\a\java.hprof

此方法可以在内存溢出的时候dump出.hprof文件。可以下载到windows本地，然后在JDK的bin目录下，文件名就叫jvisualvm.exe点击运行，选择hprof文件，就可以分析了。

最后，分析到原因了，就改bug吧。