解决fullgc_实战：响应时间偏高频繁FullGC问题定位和解决

点击上方蓝字关注我们

现象描述：

一次做性能测试时候，当并发增加到200时，响应时间超过1s，观察GC情况发现FullGC十分频繁。

问题定位：

定位方法：多次 jmap -histo pid命令查看，观察哪些对象占用内存或者调用比较多。

num #instances #bytes class name----------------------------------------------1: 6979518 959783960 [C2: 6123933 195965856 java.lang.String3: 298024 97316080 [B4: 1800366 73836920 [Ljava.lang.Object;5: 2996524 71916576 java.lang.Long6: 1266686 40533952 java.util.HashMap$Entry7: 270250 38493640 [I8: 292810 37479680 com.xxxxxx.xxx.course.web.vo.CourseVo9: 397295 33710448 [Ljava.util.HashMap$Entry;10: 253574 32457472 com.xxxxxx.xxx.course.domain.Course11: 1132839 27188136 java.util.Date12: 966535 23196840 java.util.ArrayList13: 144485 20805840 com.mysql.jdbc.Field14: 367957 17661936 java.util.HashMap15: 352464 14098560 com.xxxxxx.xxx..course.web.vo.LectorVo16: 269349 12928752 com.xxxxxx.xxx..course.domain.CourseLearnRecord17: 77529 11410000 

发现

com.xxxxxx.xxxx.course.web.vo.CourseVo该对象比较多，使得Ygc处理不过来，晋升到old区，逐渐使得old区空间增长迅速，导致频繁fullgc

使用Nprofile定位，发现存在循环调用

问题原因：

1. courseVo对象比较大的原因是因为String类型的拼接都是使用的string + 的方式，没有使用stringBuidler or StringBuffer的方式

2. dao层循环调用是开发实现方式问题

解决方法：

1. 把所有VO层的string拼接都改成StringBuffer or StringBuilder等方式

2. 修改实现方式

解决后表现：

同样并发200，TPS 从852提升到接近1876，平均响应时间从1s降到100ms左右

借鉴意义：

1. string这种常用的类型使用方式一定要注意，尤其是数据量比较大时，一定注意不要使用string + 的方式进行字符串拼接

2. 避免DAO层循环调用

添加微信加入讨论小组