又是一个客户的问题，客户的生产服务掉线了。微笑）;如果是其他故障引起的，系统日志已经提示了，还可以寻求我们的帮助吗？花了一整天的时间才拿到客户端的转储文件。我要在这里抱怨。我无法设置传输系统或其他东西。我只能通过已经归档的移动硬盘来测试东西。一个部门这么多人要借，等了好久，人家下班后轮到我们借了。谁知道生产测试是不是拿到了一些敏感信息，不知道安全部门怎么想的。1、问题现象几经波折，分析得到的dump，发现java.util.ArrayList占用空间很大。2.排查过程仔细看看是不是都是这个实体类引起的。[com.cupdata.upcoas.model.Apply]对该实体类进行了查询以查看找到的内容。这个对象有30W左右，每个平均8k左右，所以最后一个对象大约占\(300000*8/1024/1024=2.28G\)我理解客户端的服务器是4C16G的机器，java进程做不要给-Xms-Xmx参数。因为JVM分配的最大内存是由-Xmx指定的，默认是物理内存的1/4。排查发现进程没有配置-Xms-Xmx，所以进程最大内存只有4G。三、解决方案1、手动设置jvm堆内存大小，加入如下启动参数：-Xms6g-Xmx6g-XX:+UseG1GC-XX:+PrintGCDetails-XX:+HeapDumpOnOutOfMemoryError堆内存可根据情况上下调整物理内存和实际情况。对于6G以上的大堆，使用G1垃圾收集器会有更好的性能体验；配置转储文件，当内存溢出时自动生成转储文件，以便分析问题；配置gc日志，分析gc问题；2.设置ArrayList初始化Size如果Apply对象存储在自定义创建的ArrayList中，在新建ArrayList数组时配置初始大小，避免其自动扩容。4.思考这只是对dump文件的初步分析，稍后我们会去客户现场查看详情，等待后续更新。
