又是一次客户問題，客户生產上服務一直無緣掉線，瞭解了半天，大概率是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文件進行的一次初步分析，具體後面會在到客户現場排查，等着後面更新吧。