作者：京东科技 韩国凯
一、问题发现与排查
1.1 找到问题原因
通过泰山查看该机器内存使用情况：
但是内存使用率并不高，只有62%，属于正常范围内。
后面根据其他指标，例如流量的突然进入也怀疑过是jsf接口被突然大量调用导致的cpu占满，所以内存使用率不高，不过后面都慢慢排除了。其实在这里就有点一筹莫展了，现象与猜测不符，只有CPU增长而没有内存增长，那么什么原因会导致单方面CPU增长？然后又朝这个方向排查了半天也都被否定了。
会不会是监控有“问题”？
JVM的使用的CPU是在机器上能体现出来的，而JVM的堆内存高额使用之后在机器上体现的并不是很明显。
那么此时可以确定，是Full GC引起的问题。
1.2 找到FULL GC的原因
然后使用JPofiler进行内存分析。（JProfiler是一款堆内存分析工具，可以直接连接线上jvm实时查看相关信息，也可以分析dump出来的堆内存快照，对某一时刻的堆内存情况进行分析）
.bin，然后打开即可。（我们使用行云上自带的dump小工具，也可以自己去机器上通过命令手工dump文件）
从图中可以看出，四个List对象就占据了近900MB的内存，而我们刚刚看到堆内存最大也只有1.3GB，因此再加上其他的对象，很容易就会把老年代占满引发full gc的问题。
最大的对象作为我们要查看的对象
在这里也可以看到Map中的相关属性信息。
至此，我们理论上已经找到了大对象在代码中的位置。
二、问题解决
2.1 找到大对象在代码中的位置与问题的根本原因
我们的项目中大概逻辑是这样的：
- 首先会解析用户上传的Excel样本，并将其加载到内存中作为一个List变量，即我们上述看到的变量。一个20w的样本，此时字段数量有a个，大概占用空间100mb左右。
- 然后遍历循环用户样本，根据用户样本中的数据，再增加一些额外的请求数据，根据此数据请求相关结果。此时字段数量有a+n个，占用空间已经在200mb左右。
- 循环完成后将此200mb的数据存入缓存。
- 开始生成excel，将200mb数据从缓存中取出，并根据之前记录的a个字段，取出初始的样本字段填充至excel。
结论：
List<Map<String, String>>的结构存储起来，首先一个20mb的excel文件以此方式存储会膨胀占用120mb左右堆内存，此步骤会大量占用堆内存，并且因为任务逻辑原因，该大对象内存会在jvm中存在长达4-12小时之久，导致一但任务过多，jvm堆内存很容易被打满。
一个Long对象占内存计算：在HashMap<Long，Long>结构中，只有Key和Value所存放的两个长整型数据是有效数据，共16字节（2×8字节）。这两个长整型数据包装成java.lang.Long对象之后，就分别具有8字节的MarkWord、8字节的Klass指针，再加8字节存储数据的long值（一个包装对象占24字节）。
——《深入理解Java虚拟机》5.2.6
空间效率17.1mb/128mb≈13.4%
2.2 如何解决此问题
一类是治本，即不把该对象放入jvm内存中，转而存入缓存中，不在内存中则大对象问题自然迎刃而解。另一类是治标，即缩小该大内存对象，在日常使用场景下使其一般不会触发频繁的full gc问题。
2.2.1 激进治疗：不把他存入内存
解决逻辑也很简单，例如在加载数据时，将其按照样本加载数据一条一条存入redis缓存，然后我们只需要知道样本中有多少的数量，按照数量的先后顺序从缓存中取出数据，即可解决该问题。
缺点：首先会增加许多redis缓存空间消耗，其次从显示考虑对于我们项目来说，此处代码古老且晦涩难懂，改动需要较大工作量与回归测试。
2.2.2 保守治疗：缩减其数据量
其次是在第二步中，多出来的字段n，在请求结束后该字段就已经无用了，因此可以考虑在请求结束后删除无用字段。
只删除无用字段缩减其map大小，然后将其作为参数传递给生成excel使用；另一种方式是请求完成直接删除该map，然后在生成excel时再重新读取用户上传的excel样本。
缺点：在极端大数据量情况下，仍有可能出现full gc的情况
其中一种实现方式
//获取有用的字段
String[] colEnNames = (String[] colNameMap.get(Constant.BATCH_COL_EN_NAMES;
List<String> colList = Arrays.asList(colEnNames;
//去除无用的字段
param.keySet(.removeIf(key -> !colList.contains(key;
三、拓展思考
首先本文中监控图是在复现当时场景时人为制造的gc常见。
但是并没有出现当时场景中的104%的CPU使用率。
频繁出现。
那么当时的场景是什么原因呢？
堆内存中的大对象是会随着任务的进行逐步膨胀的，那么当我们的任务足够多，时间足够长，就有可能导致每次full gc后可用空间变得越来越小，当可用空间小到一定程度之后就，每次full gc完成之后发现空间还是不够使用，就会触发下一次的gc，从而导致最终结果的频繁发生gc，引起cpu频率的飙升不下。
四、问题排查总结
- 当我们遇到线上cpu使用率过高的情况时，可以先查看是否是full gc引起的问题，注意要看的是jvm的监控，或者使用jstat相关命令查看。不要被机器内存监控所误导。
- 如果确定是gc引起的问题，可以通过JProfiler直连线上jvm或者使用dump保存堆快照后离线分析。
- 首先可以找到最大的对象，一般情况下是大对象引起的full gc。还有一种情况是，不像这么明显是四个大对象，也可能是比较均衡的十几个50mb的对象，具体情况还需要具体分析。
- 通过上述工具找到确定有问题的对象后找到其堆栈对应的代码位置，通过代码分析找到问题的具体原因，通过其他现象推演猜测是否正确，进而找到问题的真正原因。
- 根据问题的原因解决此问题。
当然，上述只是不算很复杂的排查情况，不同的系统肯定有不同的内存情况，我们应当具体问题具体分析，而从此次问题中可以学到的就是如果排查解决问题的思路。