通过gc日志查找java服务可能存在需要优化的地方

lichaofan1

已于 2022-06-28 15:42:03 修改

阅读量158

点赞数

分类专栏： JVM 文章标签： java jvm 算法

于 2022-06-24 15:33:41 首次发布

本文链接：https://blog.csdn.net/lichaofan1/article/details/125445772

版权

JVM 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

通过jps来查找当前服务器运行的java进程，并找到自己进程的pid

服务的名称应该和自己启动的类名差不多。
在这里插入图片描述

通过jstat -gc pid 命令查看程序运行过程中jvm的GC垃圾回收信息。

C:\Users\81533>jstat -gc 11832 1000 100
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
131072.0 131072.0  0.0    0.0   786432.0 613436.7  524288.0     0.0     4480.0 770.4  384.0   75.9       0    0.000   0      0.000    0.000
131072.0 131072.0  0.0   131023.8 786432.0 786432.0  524288.0   524160.0  4480.0 770.4  384.0   75.9       1    0.000   0      0.000    0.000
131072.0 131072.0  0.0   131072.0 786432.0 386057.8  524288.0   67028.0   34176.0 32219.3 4736.0 4353.8      1    0.048   0      0.000    0.048
131072.0 131072.0 131072.0  0.0   786432.0 124251.0  524288.0   358894.4  34432.0 32507.5 4736.0 4393.4      2    0.137   0      0.000    0.137
131072.0 131072.0 131072.0  0.0   786432.0 648407.9  524288.0   358894.4  34432.0 32507.5 4736.0 4393.4      2    0.137   0      0.000    0.137
131072.0 131072.0  0.0    0.0   786432.0 381361.8  524288.0   153176.9  34432.0 32506.4 4736.0 4392.9      3    0.137   3      0.109    0.246
131072.0 131072.0  0.0    0.0   786432.0 113486.7  524288.0   416589.7  34432.0 32506.4 4736.0 4392.9      4    0.214   4      0.216    0.430
131072.0 131072.0  0.0    0.0   786432.0 634691.3  524288.0   416589.7  34432.0 32506.4 4736.0 4392.9      4    0.214   4      0.216    0.430
131072.0 131072.0  0.0    0.0   786432.0 731223.1  524288.0   416570.1  34432.0 32506.4 4736.0 4392.9      5    0.214   7      0.236    0.450
131072.0 131072.0  0.0    0.0   786432.0 368933.0  524288.0   164784.1  34432.0 32506.4 4736.0 4392.9      5    0.214   7      0.315    0.529
131072.0 131072.0  0.0    0.0   786432.0 100818.5  524288.0   430898.0  34432.0 32506.4 4736.0 4392.9      6    0.214   8      0.436    0.650
131072.0 131072.0  0.0    0.0   786432.0 619863.3  524288.0   430898.0  34432.0 32506.4 4736.0 4392.9      6    0.214   8      0.436    0.650
131072.0 131072.0  0.0    0.0   786432.0 349165.1  524288.0   181693.3  34432.0 32506.4 4736.0 4392.9      7    0.214  11      0.537    0.752
131072.0 131072.0  0.0    0.0   786432.0   0.0     524288.0   448214.7  34432.0 32506.4 4736.0 4392.9      8    0.284  12      0.722    1.006
131072.0 131072.0  0.0    0.0   786432.0 80914.2   524288.0   448214.7  34432.0 32506.4 4736.0 4392.9      8    0.284  12      0.722    1.006
131072.0 131072.0  0.0    0.0   786432.0 592833.4  524288.0   448214.7  34432.0 32506.4 4736.0 4392.9      8    0.284  13      0.727    1.011
131072.0 131072.0  0.0    0.0   786432.0 314965.1  524288.0   207707.2  34432.0 32506.4 4736.0 4392.9      9    0.284  15      0.805    1.088
131072.0 131072.0  0.0    0.0   786432.0 36884.2   524288.0   485029.2  34432.0 32506.4 4736.0 4392.9     10    0.284  17      0.909    1.193
131072.0 131072.0  0.0    0.0   786432.0 550783.1  524288.0   485029.2  34432.0 32506.4 4736.0 4392.9     10    0.284  18      0.918    1.202
131072.0 131072.0  0.0    0.0   786432.0 273996.2  524288.0   249508.1  34432.0 32508.2 4736.0 4393.4     11    0.284  19      0.991    1.275
131072.0 131072.0  0.0    0.0   786432.0  9732.1   524288.0   15405.2   34432.0 32508.2 4736.0 4393.4     12    0.284  20      1.025    1.309
131072.0 131072.0  0.0    0.0   786432.0 523409.9  524288.0   15405.2   34432.0 32508.2 4736.0 4393.4     12    0.284  20      1.025    1.309
131072.0 131072.0  0.0   131072.0 786432.0 257353.2  524288.0   142765.6  34432.0 32508.2 4736.0 4393.4     13    0.318  20      1.025    1.344
131072.0 131072.0  0.0   131072.0 786432.0 768645.0  524288.0   142765.6  34432.0 32508.2 4736.0 4393.4     13    0.318  20      1.025    1.344
131072.0 131072.0 130047.3  0.0   786432.0   0.0     524288.0   142766.4  34432.0 32508.2 4736.0 4393.4     14    0.322  20      1.025    1.347

通过列FGC 可以看到老年代的gc次数在不断的增大，并且full gc的次数居然还大于minor gc，都知道年轻代的对象都是朝生夕死的，消亡的很快，而老年代的对象并不会有很大的变化，那么为什么会导致老年代清理次数居然大于年轻大呢?
通过gc信息可以看到，eden区满了，应该是进行minor gc，然后将对象移动到s1区了，然后s0区满了之后，eden区的内存也差不多是满的，但是元空间也是满的状态，然后就开始出现了full gc。说明有大量的对象频繁的被挪动到老年代。

在这里插入图片描述

这时候通过jmap -histo查看一下jvm中所有的对象。

在这里插入图片描述

发现有大量的User对象存在。这个可能是问题所在，但不确定，还必须找到对应的代码确认，如何去找对应的代码了？
1、代码里全文搜索生成User对象的地方(适合只有少数几处地方的情况)
2、如果生成User对象的地方太多，无法定位具体代码，我们可以同时分析下占用cpu较高的线程，一般有大量对象不断产生，对应的方法代码肯定会被频繁调用，占用的cpu必然较高。

超链接：查看占用cpu较高的程序