二、问题解决
2.1 找到大对象在代码中的位置与问题的根本原因
首先我们根据上述过程找到对应位置与逻辑
我们的项目中大概逻辑是这样的：
- 首先会解析用户上传的Excel样本，并将其加载到内存中作为一个List变量，即我们上述看到的变量。一个20w的样本，此时字段数量有a个，大概占用空间100mb左右。
- 然后遍历循环用户样本，根据用户样本中的数据，再增加一些额外的请求数据，根据此数据请求相关结果。此时字段数量有a+n个，占用空间已经在200mb左右。
- 循环完成后将此200mb的数据存入缓存。
- 开始生成excel，将200mb数据从缓存中取出，并根据之前记录的a个字段，取出初始的样本字段填充至excel。
用流程图表示为：
结合一些具体排查问题的图片：
其中一个现象是每次gc后的最小内存正在逐步变大，对应上述步骤中第二步，内存正在逐步膨胀。
结论：
将用户上传的excel样本加载到内存中，并将其作为一个List>的结构存储起来，首先一个20mb的excel文件以此方式存储会膨胀占用120mb左右堆内存，此步骤会大量占用堆内存，并且因为任务逻辑原因，该大对象内存会在jvm中存在长达4-12小时之久，导致一但任务过多，jvm堆内存很容易被打满。
这里列举了为什么使用HashMap会导致内存膨胀，其主要原因是存储空间效率比较低：
一个Long对象占内存计算：在HashMap结构中，只有Key和Value所存放的两个长整型数据是有效数据，共16字节（2×8字节）。这两个长整型数据包装成java.lang.Long对象之后，就分别具有8字节的MarkWord、8字节的Klass指针，再加8字节存储数据的long值（一个包装对象占24字节）。
然后这2个Long对象组成Map.Entry之后，又多了16字节的对象头（8字节MarkWord+8字节Klass指针=16字节），然后一个8字节的next字段和4字节的int型的hash字段（8字节next指针+4字节hash字段+4字节填充=16字节），为了对齐，还必须添加4字节的空白填充，最后还有HashMap中对这个Entry的8字节的引用，这样增加两个长整型数字，实际耗费的内存为(Long(24byte)×2)+Entry(32byte)+HashMapRef(8byte)=88byte，空间效率为有效数据除以全部内存空间，即16字节/88字节=18%。
——《深入理解Java虚拟机》5.2.6
以下是刚上传的excel中dump出的堆内存对象，其占用的内存达到了128mb，而上传的excel实际只有17.11mb。
