讲一讲jvm调优

单纯讲命令有点枯燥而且也不知道怎么用，我用场景来驱动命令的讲解

1.爆内存场景

这时我们可以用jmap导出堆dump hprofile，可以用过mat analysis工具分析哪个类比较多出现，可以通过堆栈跟踪找到创建该类的出处

2.爆cpu场景

首先我们 通过top查出对应的进程id，top -p 进程号 定位到进程再加个-H可以查出该进程下面的线程，此时就可以拿到占用cpu较高的线程号，此时是十进制，转化为十六进制后，利用jstack查出jvm中线程的信息，通过我们上面查到的线程号就可以跟踪到该线程对应的堆栈，从而找到代码出处

 

3.避免fullgc调优

通过jstat 查出 ygc，ogc的频率

如果full gc太过频繁的话，

那么，我们可以推测一下到此fullgc频繁的原因，首先，导致full gc就是因为old区的对象已经占满了该区的指定比例，也就是说从年轻代挪过来的对象有点多了，

那是为什么年轻代会挪那么多对象过来呢

而年轻代挪兑现过来老年代的情况大致有下面四种

1.对象年龄到底指定的年龄自动存进老年代

2.动态年龄判断，当jvm识别到要挪进去survior区的对象大小超过指定占用survivor比例的时候会将超出比例的对象按年龄最老的对象挪进老年代

3.老年代空间担保， 每次ygc前jvm都会计算下当前老年代剩余的空间是否大于等于当前年轻代所有对象的和，如果不够，那么就会计算下=此前回收年轻代进入老年代的对象的平均大小，如果还不够，那么就会触发fullgc

4.大对象直接进入老年代,超过指定大小的对象直接进入老年代

到这里，我们可以分析到，1的情况是属于正常的流转流程，4的话我们就要分析是否有大对象生成，2和3的话我们通过调高年轻代的大小都可以很好的避免类似的情况发生

而分析大对象生成，可以通过jmapdump出堆栈信息，查找是否有我们自己创建的对象在堆栈中显示，如果 有，我们可以拿到对应的对象，

此时代码中创建该对象的地方很多，一种方法使我们直接全局搜索，但是如果项目很大的话，我们是很难定位到问题代码的，那么我们还可以通过通过jstack分析线程堆栈，查找出频繁创建该对象的线程所在的堆栈信息，那么就可以定位到频繁创建此对象的代码。从而定位到问题

 

到此，我把三种最常见场景的分析都大致说了下思路，细节部分还需要自己琢磨和分析。有不足之处敬请指教.