工作中遇到的java 内存溢出，问题排查

工作中遇到的java 内存溢出，问题排查

一、服务器配置及jvm运行参数

1. CentOS release 6.4 (Final)
2. MemTotal: 16333916 kB
3. Intel(R) Xeon(R) CPU E7-4860 v2 @ 2.60GHz 8C

4. -Xmx4096m -Xms4096m -XX:MaxPermSize=512m -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/heap/dump -server

   二、内存溢出场景
   800并发压测，一个小时，出现了内存溢出。
   三、问题排查
   通过查看gc情况可以看出当压测到半个小时的时候就出现了频繁FGC 如下图：

jstat -gc 7098 2000
 S0C    S1C      S0U    S1U      EC       EU        OC         OU       PC      PU         YGC   YGCT    FGC    FGCT     GCT   
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796242.3  90112.0 50428.6    348   25.295   8     37.453   62.748
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796242.3  90112.0 50428.6    348   25.295   8     37.453   62.748
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796242.3  90112.0 50428.6    348   25.295   8     37.453   62.748
17920.0 17920.0  0.0    0.0   1362432.0 1289751.1 2796544.0  2796395.6  84992.0 50428.6    348   25.295   8     43.144   68.439
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796395.6  84992.0 50428.6    348   25.295   9     43.144   68.439
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796395.6  84992.0 50428.6    348   25.295   9     43.144   68.439
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796395.6  84992.0 50428.6    348   25.295   9     43.144   68.439
17920.0 17920.0  0.0    0.0   1362432.0 1286917.0 2796544.0  2796468.2  80896.0 50428.6    348   25.295   9     49.018   74.313
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796468.2  80896.0 50428.6    348   25.295  10     49.018   74.313
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796468.2  80896.0 50428.6    348   25.295  10     49.018   74.313
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796468.2  80896.0 50428.6    348   25.295  10     49.018   74.313
17920.0 17920.0  0.0    0.0   1362432.0 1263355.4 2796544.0  2796045.4  76800.0 50428.6    348   25.295  10     54.915   80.210
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796045.4  76800.0 50428.6    348   25.295  11     54.915   80.210
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796045.4  76800.0 50428.6    348   25.295  11     54.915   80.210
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796045.4  76800.0 50428.6    348   25.295  11     54.915   80.210
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796127.0  73216.0 50428.6    348   25.295  12     60.780   86.075
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796127.0  73216.0 50428.6    348   25.295  12     60.780   86.075
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796127.0  73216.0 50428.6    348   25.295  12     60.780   86.075
17920.0 17920.0  0.0    0.0   1362432.0 600666.6  2796544.0  2796332.0  70144.0 50428.6    348   25.295  12     66.545   91.840

半个小时的时候就出现了8S一次FGC，YGC基本不变。通过GC情况就可以分析出，在老年代出现了一个大对象，一直回收不下去，这样就可以定位问题了，可以通过分析jvm的内存快照。

分析jvm内存dump文件

jmap -dump:format=b,file=/opt/appdump.bin 7098

生成了dump文件通过eclipse memory analysis 插件进行分析。由于dump文件较大，先得调整eclipse jvm参数

 

 哇，一个LinkedBlockingQueue无界队列占jvm94.48%

分析代码看到了，原来是生产者比消费者快的多。导致这样的问题。最后加大了消费者的速度，跟消费者的数量。

以上是我工作上遇到的问题，如果大家发现了问题，可以跟我一起来探讨

转载于：https://blog.csdn.net/zgliang88/article/details/49863337?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.control