工作中遇到的java 内存溢出，问题排查
一、服务器配置及jvm运行参数
- CentOS release 6.4 (Final)
- MemTotal: 16333916 kB
- Intel(R) Xeon(R) CPU E7-4860 v2 @ 2.60GHz 8C
-
-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
