jvm学习——实际项目调优

1.原项目未进行gc调优

发送了4000次yonggc 和80多次的full gc 停顿时间达到45秒

1.和配置gc参数

选用CMS垃圾处理器，并配置堆内存

2.修改日志输出等级

观察到生产环境日志的输出等级为info修改为error

log4j.logger.p6spy=info,stdout,spyFile

级别info修改为error

log4j.logger.p6spy=error,stdout,spyFile​

效果不明显

3.增大初始堆内存大小

修改堆内存大小，将最小堆内存与最大堆内存调整一致。

4.dump堆内存分析

总共dump了三天的日志，查看是否发生内存泄漏，使用mat进行内存分析。
使用包的形式分析类，横向对比两天的对象变化

定位代码：


查看代码，发现公司的产品的这三个对象都是进行了json的转换，而使用的是GSONutils，发现里面的json转换有问题
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v0B7anNc-1590145354765)(https://www.xupeng.life/upload/2020/05/image-16c1c07cf2f24728845dd760bf3d87d4.png)]
每次都是new一个新的GSON对象进行转换，可能导致问题出现
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jmiEFpZp-1590145354766)(https://www.xupeng.life/upload/2020/05/image-a713b7eaa0524ddd86aabe372e49069b.png)]
这个待测试

2.待调整

这台服务器的访问量是最大的，而且访问次数最多的服务器，待申请进行调整

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bu8k1bZb-1590145354767)(https://www.xupeng.life/upload/2020/05/image-a43db14ecccb433e9bcdf3593022c05d.png)]

3.yonggc次数多

堆内存信息查看

gc时间查看

调整参数

-XX:CMSInitiatingOccupancyFraction=70  使用cms作为垃圾回收使用70％后开始CMS收集

调整70 80的区别

-XX:+UseParNewGC ## 对年轻代采用多线程并行回收，这样收得快
-XX:+UseCMSCompactAtFullCollection  在FULL GC的时候对年老代的压缩，Full GC后会进行内存碎片整理，过程无法并发，空间碎片问题没有了，但提顿时间不得不变长了

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BDeEUtwe-1590145354770)(https://www.xupeng.life/upload/2020/05/image-251d1458e0da4024b9331286eea76aec.png)]

set JAVA_OPTS=-Xms1024m -Xmx1024m -XX:MetaspaceSize=2048m -XX:MaxMetaspaceSize=2048m -XX:+UseConcMarkSweepGC -XX:SurvivorRatio=8 -XX:CMSInitiatingOccupancyFraction=70 -XX:CMSFullGCsBeforeCompaction=3 -XX:+UseCMSCompactAtFullCollection -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:D:/成都局项目/gc/gc.log

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zM498OER-1590145354772)(https://www.xupeng.life/upload/2020/05/image-b7601cbd8f444e3484c35c3456680575.png)]