分析Java生产环境下问题排查思路-创新互联

这篇文章主要介绍“分析Java生产环境下问题排查思路”，在日常操作中，相信很多人在分析Java生产环境下问题排查思路问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”分析Java生产环境下问题排查思路”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

Java生产环境下问题排查

在生产环境中，我们无法通过断点调试、新增log、可视化工具去立马查看当前的运行状态和拿到错误信息，此时，借助Java自带的命令行工具以及相关dump分析工具以及一些小技巧，可以大大提升我们排查问题的效率。

运行参数

下面会列出一些常用且非常有效的命令以及参数来查看运行时Java程序的信息，从而辅助你了解程序运行状态。

查看JVM参数

jps -l 查看所有正在运行的Java程序，同时显示启动类类名，获取到PID。

4706 org.apache.catalina.startup.Bootstrap

5023 sun.tools.jps.Jps

jinfo -flags PID 查看运行时进程参数与JVM参数

Attaching to process ID 28987, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 25.171-b11

Non-default VM flags: -XX:CICompilerCount=3 -XX:InitialHeapSize=132120576 -XX:MaxHeapSize=2092957696 -XX:MaxNewSize=697303040 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=44040192 -XX:OldSize=88080384 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC

Command line: -Dspring.config.location=application.properties -Dspring.profiles.active=staging

java -XX:+PrintFlagsFinal -version 查看当前虚拟机默认JVM参数

查看即时GC状态

jstat -gc PID 1000 10 每秒查看一次gc信息，共10次，输出比较多的参数。

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT

512.0 512.0 15.3 0.0 4416.0 1055.2 11372.0 7572.5 14720.0 14322.5 1664.0 1522.8 40 0.137 8 0.039 0.176

期间可能碰到提示sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 24.181-b01. Target VM is 25.171-b11的问题，原因在于安装了多个版本，使用which、ls -l可简介定位到与当前执行Java程序相同的Java版本。

错误排查

内存问题

内存泄露导致OOM?内存占用异常的高?这是生产环境常常出现的问题，Java提供dump文件供我们对内存里发生过的事情进行了记录，我们需要借助一些工具从中获取有价值的信息。

导出Dump文件

提前对Java程序加上这些参数印dump文件 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./

对正在运行的程序使用jmap：jmap -dump:format=b,file=heap.hprof PID

分析Dump文件

如果Dump文件不太大的话，可以传到指定渠道来分析。文件比较大，且想进行更加系统的分析，推荐使用MAT分析，有如下几种常用查看方式：

首页中的【Leak Suspects】能推测出问题所在;

点击【Create a histogram from an arbitrary set of objects】查到所有对象的数量;

右键点击某个对象【Merge Shortest Paths to GC Roots】-> 【exclude all phantom/weak/soft etc. references】能查询到大量数量的某个对象是哪个GC ROOT引用的。

线程问题

任务长时间不退出?CPU 负载过高?很可能因为死循环或者死锁，导致某些线程一直执行不被中断，但是不报错是最烦人的，所以日志里看不到错误信息，并且又不能用dump文件分析，因为跟内存无关。这个时候就需要用线程分析工具来帮我们了。

导出jstack文件

使用jstack PID > 文件，如果失败请加-F参数，如果还失败请使用Java程序启动时使用的用户执行jstack，下面是jstack的部分输出格式：

线程名 PID的16进制

"http-nio-8080-Acceptor-0" #17 daemon prio=5 os_prio=0 tid=0x00007fac2c4bd000 nid=0x29f4 runnable [0x00007fac192f6000]

java.lang.Thread.State: RUNNABLE(tomcat的工作线程正在运行，有NEW/RUNNABLE/BLOCKED/WAITING/TIMED_WATING/TERMINATED状态)

at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)

at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)

at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)

- locked<0x00000000faf845a8>(a java.lang.Object)

at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:682)

at java.lang.Thread.run(Thread.java:748)

jstack的输出可以看到所有的线程以及他们的状态，我们就可以看有哪些我们自己创建的正在运行的线程，那很可能就是那个一直在执行的线程了，此时线程名就格外重要了，所以建议创建新线程时指定有意义的线程名。当然，通过PID查找也非常方便。

到此，关于“分析Java生产环境下问题排查思路”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！