Java自带的性能监测工具用法简介

https://blog.csdn.net/xad707348125/article/details/51985854

https://www.cnblogs.com/yjd_hycf_space/p/7755633.html

http://www.cnblogs.com/alipayhutu/archive/2012/08/20/2647353.html

问题： 发现jstat，jmap等命令不存在的

解决： 

yum install java-1.8.0-openjdk-devel-debug

问题： Unable to open socket file: target process not responding or HotSpot VM not loaded 

Unable to open socket file: target process not responding or HotSpot VM not loaded

The -F option can be used when the target process is not responding

解决：

在用jstack工具查看jvm线程的运行情况时出现上述错误。就是因为该进程长时间没有启停，在/tmp/hsperfdata_'username'/文件夹下的该进程文件被Linux自身的机制（tmp下面不能存放很多文件）删除，需重新启停。所以要注意/etc/cron.daily/tmpwatch改文件在生产的情况。否则出现内存泄漏，或者内存溢出时，很难排查，或者出现系统运行缓慢时，想要观察系统运行情况也没办法，再或者，想把现场保存至dump文件中，等待大神解决也不能做。

对线上服务器的java应用dump操作时发现，以下报错，不能dump。jps也获取不到java进程的pid。

# jmap -dump:file=/data/dump/jvm_en.hprof 20176

20176: Unable to open socket file: target process not responding or HotSpot VM not loaded

The -F option can be used when the target process is not responding

重启后，jps可以获得该java进程的pid，jstack也可以dump线程。

 

jps

• 查看所有的jvm进程，包括进程ID，进程启动的路径等等。
• 我自己也用PS，即：ps -ef | grep java

jstack

• 观察jvm中当前所有线程的运行情况和线程当前状态。
• 系统崩溃了？如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。
• 系统hung住了？jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。

jstat

• jstat利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对进程的classloader，compiler，gc情况；
• 特别的，一个极强的监视内存的工具，可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量，以及加载类的数量。

 

jmap

• 监视进程运行中的jvm物理内存的占用情况，该进程内存内，所有对象的情况，例如产生了哪些对象，对象数量；
• 系统崩溃了？jmap 可以从core文件或进程中获得内存的具体匹配情况，包括Heap size, Perm size等等

 

jinfo

• 观察进程运行环境参数，包括Java System属性和JVM命令行参数
• 系统崩溃了？jinfo可以从core文件里面知道崩溃的Java应用程序的配置信息。

 jstat命令查看jvm的GC情况 （以Linux为例）

 

 jstat命令可以查看堆内存各部分的使用量，以及加载类的数量。命令的格式如下：

 jstat [-命令选项] [vmid] [间隔时间/毫秒] [查询次数]

 注意！！！：使用的jdk版本是jdk8.

 

  类加载统计：

　

• Loaded:加载class的数量
• Bytes：所占用空间大小
• Unloaded：未加载数量
• Bytes:未加载占用空间
• Time：时间

 

  编译统计

　

• Compiled：编译数量。
• Failed：失败数量
• Invalid：不可用数量
• Time：时间
• FailedType：失败类型
• FailedMethod：失败的方法

 

  垃圾回收统计

　

• S0C：第一个幸存区的大小
• S1C：第二个幸存区的大小
• S0U：第一个幸存区的使用大小
• S1U：第二个幸存区的使用大小
• EC：伊甸园区的大小
• EU：伊甸园区的使用大小
• OC：老年代大小
• OU：老年代使用大小
• MC：方法区大小
• MU：方法区使用大小
• CCSC:压缩类空间大小
• CCSU:压缩类空间使用大小
• YGC：年轻代垃圾回收次数
• YGCT：年轻代垃圾回收消耗时间
• FGC：老年代垃圾回收次数
• FGCT：老年代垃圾回收消耗时间
• GCT：垃圾回收消耗总时间

 

  堆内存统计

　 

• NGCMN：新生代最小容量
• NGCMX：新生代最大容量
• NGC：当前新生代容量
• S0C：第一个幸存区大小
• S1C：第二个幸存区的大小
• EC：伊甸园区的大小
• OGCMN：老年代最小容量
• OGCMX：老年代最大容量
• OGC：当前老年代大小
• OC:当前老年代大小
• MCMN:最小元数据容量
• MCMX：最大元数据容量
• MC：当前元数据空间大小
• CCSMN：最小压缩类空间大小
• CCSMX：最大压缩类空间大小
• CCSC：当前压缩类空间大小
• YGC：年轻代gc次数
• FGC：老年代GC次数

 

  新生代垃圾回收统计

　

• S0C：第一个幸存区大小
• S1C：第二个幸存区的大小
• S0U：第一个幸存区的使用大小
• S1U：第二个幸存区的使用大小
• TT:对象在新生代存活的次数
• MTT:对象在新生代存活的最大次数
• DSS:期望的幸存区大小
• EC：伊甸园区的大小
• EU：伊甸园区的使用大小
• YGC：年轻代垃圾回收次数
• YGCT：年轻代垃圾回收消耗时间

 

  新生代内存统计

　

• NGCMN：新生代最小容量
• NGCMX：新生代最大容量
• NGC：当前新生代容量
• S0CMX：最大幸存1区大小
• S0C：当前幸存1区大小
• S1CMX：最大幸存2区大小
• S1C：当前幸存2区大小
• ECMX：最大伊甸园区大小
• EC：当前伊甸园区大小
• YGC：年轻代垃圾回收次数
• FGC：老年代回收次数

 

  老年代垃圾回收统计

　

• MC：方法区大小
• MU：方法区使用大小
• CCSC:压缩类空间大小
• CCSU:压缩类空间使用大小
• OC：老年代大小
• OU：老年代使用大小
• YGC：年轻代垃圾回收次数
• FGC：老年代垃圾回收次数
• FGCT：老年代垃圾回收消耗时间
• GCT：垃圾回收消耗总时间

 

 老年代内存统计

　

• OGCMN：老年代最小容量
• OGCMX：老年代最大容量
• OGC：当前老年代大小
• OC：老年代大小
• YGC：年轻代垃圾回收次数
• FGC：老年代垃圾回收次数
• FGCT：老年代垃圾回收消耗时间
• GCT：垃圾回收消耗总时间

 

 元数据空间统计

　

• MCMN: 最小元数据容量
• MCMX：最大元数据容量
• MC：当前元数据空间大小
• CCSMN：最小压缩类空间大小
• CCSMX：最大压缩类空间大小
• CCSC：当前压缩类空间大小
• YGC：年轻代垃圾回收次数
• FGC：老年代垃圾回收次数
• FGCT：老年代垃圾回收消耗时间
• GCT：垃圾回收消耗总时间

 

 总结垃圾回收统计

　

• S0：幸存1区当前使用比例
• S1：幸存2区当前使用比例
• E：伊甸园区使用比例
• O：老年代使用比例
• M：元数据区使用比例
• CCS：压缩使用比例
• YGC：年轻代垃圾回收次数
• FGC：老年代垃圾回收次数
• FGCT：老年代垃圾回收消耗时间
• GCT：垃圾回收消耗总时间

 

 JVM编译方法统计

　

• Compiled：最近编译方法的数量
• Size：最近编译方法的字节码数量
• Type：最近编译方法的编译类型。
• Method：方法名标识。