背景
线上服务器4核cpu突然打满，通过top命令分析后，找到cpu最高的应用，是一个java应用。 找到java应用最高cpu的线程，这里有一个脚本可以直接找到。
发现是jvm线程，猜测应该是jvm垃圾回收导致。
调用
jstat -gcutil 1000
查看gc次数，发现full gc 2s一次，基本可以判断是垃圾回收内存导致。
dump下堆内存
jmap -dump:format=b,file=test.hprof
dump下来的文件通过JProfiler进行内存分析
分析过程
打开dump文件，如下 
默认是按照实例数来排序的，从图上可以看出，基本是DeviceItemsRowData这个类太多导致。 找到对应的业务代码
点击DeviceItemsRowData，右键使用选定对象 
选择传入引用 
点击在图表中展示 
点击+ 
查看到线程号 
点击线程转储，选中查询到的线程号 
点击对应的线程号，找到相关的业务代码 
进行代码分析 
这个业务代码是根据选定时间去查询数据，可以判断是由于选取的时间段过长，返回数据量过多导致。
现在有个问题，能否查看到当时的访问参数？
根据堆栈信息找到controller入口， 
可以看到是一个post请求，那我们只要获取到这个请求的入参对象即可，因为该方法没有结束，入参对象肯定是没有垃圾回收的，那就说明还在堆中，只要找到这个对象即可。 点击根据名称排序，找到该对象 
右键->使用选中对象->传出引用 
点击确认后，选中一个对象，即可查看参数 
原来是查询了一年的数据，联系产品及开发，看看如何修复代码。