Java web应用性能分析之【6种OOM监控和分析】

Java web应用性能分析之【Linux服务器性能监控分析概叙】-CSDN博客

Java web应用性能分析概叙-CSDN博客

Java web应用性能分析之【基准测试】-CSDN博客

Java web应用性能分析之【sysbench基准测试】-CSDN博客

Java web应用性能分析之【CPU飙升分析概述】-CSDN博客

Java web应用性能分析之【CPU飙高分析之MySQL】-CSDN博客

Java web应用性能分析之【OOM监控分析之Allocation Failure】-CSDN博客

概叙

　　1. 堆溢出-java.lang.OutOfMemoryError: Java heap space。检查大对象
　　2. 栈溢出-java.lang.OutOfMemorryError：unable to create new native thread 检查多线程
　　3. 栈溢出-java.lang.StackOverFlowError。检查递归
　　4. 元信息溢出-java.lang.OutOfMemoryError: Metaspace。
　　5. 直接内存溢出-java.lang.OutOfMemoryError: Direct buffer memory。排查nio，一般重点检查netty，它里面的nio用直接内存用的多
　　6. GC超限-java.lang.OutOfMemoryError: GC overhead limit exceeded。

OOM是java应用都会遇到的错误，原因就是java进程中向jvm申请内存得不到满足，jvm没得办法发出来的错误提示。作为合格的开发，应该知道如何排查oom，以及如何解决oom。

排查OOM的步骤

1.看错误日志：“Caused by: java.lang.OutOfMemoryError: Java heap space”附近就可以看到业务代码引起oom的位置“at com.zxx.study.web.controller.OomController.javaHeapSpace(OomController.java:56)”

2.分析jvm的dump文件：如java自带工具VisualVM就能很容易分析，并定位oom位置。

3.定位oom：一般都是根据12两步，去找出代码中触发oom的点

4.合理设置jvm各个区块大小：一般通过jstat监控gc和各个区块内存使用情况，来判断我们的jvm设置是否合理。

由于篇幅限制，也便于查看，后面5种情况，将单独发文分析。当然也欢迎感兴趣的小伙伴对文章中的三个问题进行讨论。

思考问题：1.OutOfMemoryError不是Error吗，为什么回被全局Exception异常捕捉？（有兴趣的欢迎评论交流）

思考问题：2.我们的java进程就是个springboot的jar包，默认用的是tomcat服务器，都知道tomcat的线程池默认初始化10个线程来处理我们的业务请求，想想看为啥当业务线发生oom异常时，这个线程咋地还能处理业务，没有被回收？（下面监控里面还是10个线程，线程编号还是1到10）

问题思考：为什么这里发生了oom“OutOfMemoryError: Java heap space”时触发了“Allocation Failure”，但是可以恢复？只是阻碍了一会儿业务，后面业务访问就正常了？（有兴趣的欢迎评论交流）

6种OOM现象

　　1. 堆溢出-java.lang.OutOfMemoryError: Java heap space。检查大对象

从上面业务访问来看，触发了OOM后，我们的业务返回结果是“网络超时、请稍后操作”，后面用正常url访问时，业务访问正常。

思考问题：1.OutOfMemoryError不是Error吗，为什么回被全局Exception异常捕捉？（有兴趣的欢迎评论交流）

监控里面还是10个线程，线程编号还是1到10

监控情况

通过jstat 统计gc情况和jvm各个内存区快使用情况

java进程运行时日志，“Caused by: java.lang.OutOfMemoryError: Java heap space”附近就可以看到业务代码引起oom的位置“at com.zxx.study.web.controller.OomController.javaHeapSpace(OomController.java:56)”

OOM时dump了现场，可以看到当前进程4366的内存dump文件

　2. 栈溢出-java.lang.OutOfMemorryError：unable to create new native thread 检查多线程

　　3. 栈溢出-java.lang.StackOverFlowError。检查递归

　　4. 元信息溢出-java.lang.OutOfMemoryError: Metaspace。

　　5. 直接内存溢出-java.lang.OutOfMemoryError: Direct buffer memory。排查nio，一般重点检查netty，它里面的nio用直接内存用的多

　　6. GC超限-java.lang.OutOfMemoryError: GC overhead limit exceeded。

验证前的准备

1.验证6种场景的代码，见下面文章

Java web应用性能分析之【6种OOM模拟】-CSDN博客

2.模拟正常访问的业务请求：6种请求对应6个场景；异常场景只需要修改一下传入参数name=zhouxx1 只要name！=zhouxx就会触发oom。

 curl  http://127.0.0.1:6002/api/v1/oom/javaHeapSpace?name=zhouxx >/dev/null &
 curl  http://127.0.0.1:6002/api/v1/oom/stackOOM?name=zhouxx >/dev/null &
 curl  http://127.0.0.1:6002/api/v1/oom/stackOverFlow?name=zhouxx >/dev/null &
 curl  http://127.0.0.1:6002/api/v1/oom/metaspaceOOM?name=zhouxx >/dev/null &
 curl  http://127.0.0.1:6002/api/v1/oom/directBufferOOM?name=zhouxx >/dev/null &
 curl  http://127.0.0.1:6002/api/v1/oom/GCOverheadOOM?name=zhouxx >/dev/null &

3.启动参数

启动参数
JAVA_OPTS=" -server -Dfile.encoding=UTF-8 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8899 -Dcom.sun.management.jmxremote.authenticate=false -Dapp.config=/home/web/demo/application.yaml -Xms64m -Xmx64m  -Xss1m -XX:MetaspaceSize=16m -XX:MaxMetaspaceSize=64m -XX:+UseG1GC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintCommandLineFlags -Xloggc:log/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=log/"

启动命令
java $JAVA_OPTS  -jar mydemo-1.0.0-SNAPSHOT.jar

为了便于查看当前进程运行情况，这里就不跑在后台，直接打印在当前窗口上。