2.2 如何解决此问题
暂且不讨论上述流程是否合理，解决办法一般可以分为两类，一类是治本，即不把该对象放入jvm内存中，转而存入缓存中，不在内存中则大对象问题自然迎刃而解。另一类是治标，即缩小该大内存对象，在日常使用场景下使其一般不会触发频繁的full gc问题。
两种方式各有优劣：
2.2.1 激进治疗：不把他存入内存
解决逻辑也很简单，例如在加载数据时，将其按照样本加载数据一条一条存入redis缓存，然后我们只需要知道样本中有多少的数量，按照数量的先后顺序从缓存中取出数据，即可解决该问题。
优点：可以从根本上解决此问题，以后基本上不会存在该问题，数据量再大只需要添加相应的redis资源即可。
缺点：首先会增加许多redis缓存空间消耗，其次从显示考虑对于我们项目来说，此处代码古老且晦涩难懂，改动需要较大工作量与回归测试。
2.2.2 保守治疗：缩减其数据量
分析2.1的上述流程，首先第三步是完全没必要的，先存入缓存再取出，额外占用缓存空间。（猜测系历史问题，此处不再深究）。
其次是在第二步中，多出来的字段n，在请求结束后该字段就已经无用了，因此可以考虑在请求结束后删除无用字段。
此时也有两种解决方案，一种是只删除无用字段缩减其map大小，然后将其作为参数传递给生成excel使用；另一种方式是请求完成直接删除该map，然后在生成excel时再重新读取用户上传的excel样本。
优点：改动较小，不需要太复杂的回归测试
缺点：在极端大数据量情况下，仍有可能出现full gc的情况
具体实现方式就不展开了。
其中一种实现方式
//获取有用的字段
String[] colEnNames = (String[]) colNameMap.get(Constant.BATCH_COL_EN_NAMES);
List colList = Arrays.asList(colEnNames);
//去除无用的字段
param.keySet().removeIf(key -> !colList.contains(key));
三、拓展思考
首先本文中监控图是在复现当时场景时人为制造的gc常见。
在cpu使用率图中，大家可以观察到cpu使用率上升时间确实跟gc的时间相吻合，但是并没有出现当时场景中的104%的CPU使用率。
其实直接原因比较简单，就是因为系统虽然出现了full gc，但是并没有频繁出现。
小范围低频率的full gc不太会引起系统的cpu飙升，这也是我们所看到的现象。
那么当时的场景是什么原因呢？
我们上文提到过，我们在堆内存中的大对象是会随着任务的进行逐步膨胀的，那么当我们的任务足够多，时间足够长，就有可能导致每次full gc后可用空间变得越来越小，当可用空间小到一定程度之后就，每次full gc完成之后发现空间还是不够使用，就会触发下一次的gc，从而导致最终结果的频繁发生gc，引起cpu频率的飙升不下。
四、问题排查总结
● 当我们遇到线上cpu使用率过高的情况时，可以先查看是否是full gc引起的问题，注意要看的是jvm的监控，或者使用jstat相关命令查看。不要被机器内存监控所误导。
● 如果确定是gc引起的问题，可以通过JProfiler直连线上jvm或者使用dump保存堆快照后离线分析。
● 首先可以找到最大的对象，一般情况下是大对象引起的full gc。还有一种情况是，不像这么明显是四个大对象，也可能是比较均衡的十几个50mb的对象，具体情况还需要具体分析。
● 通过上述工具找到确定有问题的对象后找到其堆栈对应的代码位置，通过代码分析找到问题的具体原因，通过其他现象推演猜测是否正确，进而找到问题的真正原因。
● 根据问题的原因解决此问题。
当然，上述只是不算很复杂的排查情况，不同的系统肯定有不同的内存情况，我们应当具体问题具体分析，而从此次问题中可以学到的就是如果排查解决问题的思路。
