平时的一些trouble-shooting-定时任务执行时，服务器load过高

现象

某服务在后半夜2点执行的定时任务报警，执行失败，并且load升高报警。

监控

检查了监控，包括cpu、网卡流量、TCP连接数等都没任何异常

内存泄漏

分析gc日志，发现在执行期间频繁执行fullgc，但是heap区没有变小。

检查jvm内存

当时在load过高时，保存了两份内存文件，一份是原始的，一份是fullgc之后的存活的。进行对比。

原始内存

fullgc之后存活的内存

可以看出来在fullgc之后的其实内存没有变化，并且蓝色的区域已经沾满了3.5G，已经是整个的93.84%。

分析内存中的对象，发现在出问题的线程中。发现里面最大的hashmap存的是XXResult对象，并且这个hashmap占了整个的71.3%。

分析代码原因

在代码中找到具体的这个对象组装的位置，发现是因为请求量过大，没有对List进行分页处理。导致这个Map越来越大，并且只有这个定时任务执行完毕，这个最大的对象才会被回收，因为一直有引用。

解决问题

foreach循环里使用的业务对象进行分页，进行批量处理，把声明放到foreach循环内，在分批处理之后，之前new出来的对象自然会被回收。

线上发布验证

定时任务执行时间缩短，load正常，问题解决。