java中怎么检查内存溢出

本篇文章为大家展示了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%，分析代码看到了，原来是生产者比消费者快的多。导致这样的问题。最后加大了消费者的速度，跟消费者的数量。