线上一次oom挂机问题【案例小记】

  又是一次客户问题，客户生产上服务一直无缘掉线，了解了半天，大概率是oom导致的，因为系统自动打出来了内存dunp（会心一笑）；如果别的故障导致的问题，系统日志早提示了，还能找我们帮忙看吗！

  拿到客户的dump文件废了一天的时间，这里吐槽一下，就不能搞一个中转系统什么的，只能通过一个备案过的移动硬盘来考东西，一个部门那么多人想借用一下等了老半天，还是等人家下班后，才轮到我们借用了一下。要是生产上考下来点敏感信息啥的谁知道，不晓得安全部门咋想的。

一、问题现象

  一番周折，对拿到的dump分析了一下，看到 java.util.ArrayList 占用了好多的空间。

二、排查过程

  具体细看了一下全部都是这个实体类导致的吗， 【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

1. 堆内存视物理内存和实际情况可上下调整。对于6G以上的大堆，使用G1垃圾收集器会有更好的性能体验;
2. 配置发生内存溢出的时候自动生成转储文件，以便分析问题；
3. 配置gc日志，以便分析gc问题；

2、设置ArrayList初始化大小
  如果Apply对象是保存在自定义创建的ArrayList中的，在new ArrayList数组的时候配置初始化大小，避免其自动扩容。

四、思考

  这个只是对这个dump文件进行的一次初步分析，具体后面会在到客户现场排查，等着后面更新吧。