JVM介绍篇三:jvm性能监控及故障处理工具

csdn中看到了很多关于JVM介绍的,但是并没有看到什么讲解很好的资料
所以这里自己写一个记录下,方便日后工作中需要时可以查阅

jvm性能监控及故障处理工具

    • jstat
    • jmap
    • jhat
    • visualVM
    • jstack

jstat

使用命令jstat -gcutil pid查看gc垃圾回收整体情况

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0.00 100.00  74.51  22.04  91.31  90.01     41   57.346     0    0.000   57.346

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

jmap

使用命令jmap -dump:format=b,file=App.hpref pid在当前目录生成堆转储快照

jhat

使用命令jhat -J-Xmx500m filename分析jmap生成的堆转储快照
在http://127.0.0.1:7000/网页上查看分析内容
点击最下面的Show heap histogram查看统计信息
JVM介绍篇三:jvm性能监控及故障处理工具_第1张图片

visualVM

jhat 查看一般不够方便,所以都会使用visualVM来查看。visualVM在jdk的bin目录下就有,但是本人用jdk1.8自带的一直无法加载。
所以又自己下载了一个,下载链接https://visualvm.github.io/download.html
在这里插入图片描述
这里重新打印出mem-test.hpref文件,然后放到本地下载好的visualvm中加载
第一步:点击load
JVM介绍篇三:jvm性能监控及故障处理工具_第2张图片
第二步:选择hpref文件
JVM介绍篇三:jvm性能监控及故障处理工具_第3张图片
第三步:点击这里可以切换视图
JVM介绍篇三:jvm性能监控及故障处理工具_第4张图片
按图中步骤依次点击后查看
JVM介绍篇三:jvm性能监控及故障处理工具_第5张图片

jstack

使用命令jstack pid >xxx.log生成虚拟机当前时刻的线程快照。
之后可以使用jca39工具对日志进行分析
JVM介绍篇三:jvm性能监控及故障处理工具_第6张图片

线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合,生成线程快照的目的通常是定位线程出现长时间停顿的原因,如线程间死锁、死循环、请求外部资源导致的长时间挂起等,都是导致线程长时间停顿的常见原因。线程出现停顿时通过jstack来查看各个线程的调用堆栈,就可以获知没有响应的线程到底在后台做些什么事情,或者等待着什么资源。

dump 文件里,值得关注的线程状态有:

  1. 死锁, Deadlock(重点关注)
  2. 执行中,Runnable
  3. 等待资源, Waiting on condition(重点关注)
  4. 等待获取监视器, Waiting on monitor entry(重点关注)
  5. 暂停,Suspended
  6. 对象等待中,Object.wait() 或 TIMED_WAITING
  7. 阻塞, Blocked(重点关注)
  8. 停止,Parked

Dump文件中的线程状态含义及注意事项

  1. Deadlock:死锁线程,一般指多个线程调用间,进入相互资源占用,导致一直等待无法释放的情况。
  2. Runnable:一般指该线程正在执行状态中,该线程占用了资源,正在处理某个请求,有可能正在传递SQL到数据库执行,有可能在对某个文件操作,有可能进行数据类型等转换。
  3. Waiting on condition:该状态出现在线程等待某个条件的发生。
    具体是什么原因,可以结合 stacktrace来分析。
    最常见的情况是线程在等待网络的读写,比如当网络数据没有准备好读时,线程处于这种等待状态,而一旦有数据准备好读之后,线程会重新激活,读取并处理数据。
    在 Java引入 NewIO之前,对于每个网络连接,都有一个对应的线程来处理网络的读写操作,即使没有可读写的数据,线程仍然阻塞在读写操作上,这样有可能造成资源浪费,而且给操作系统的线程调度也带来压力。
    在 NewIO里采用了新的机制,编写的服务器程序的性能和可扩展性都得到提高。
    如果发现有大量的线程都在处在 Wait on condition,从线程 stack看, 正等待网络读写,这可能是一个网络瓶颈的征兆。
    因为网络阻塞导致线程无法执行。
    一种情况是网络非常忙,几乎消耗了所有的带宽,仍然有大量数据等待网络读写;另一种情况也可能是网络空闲,但由于路由等问题,导致包无法正常的到达。
    所以要结合系统的一些性能观察工具来综合分析,比如 netstat统计单位时间的发送包的数目,如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率,如果系统态的 CPU时间,相对于用户态的 CPU时间比例较高;如果程序运行在 Solaris 10平台上,可以用 dtrace工具看系统调用的情况,如果观察到 read/write的系统调用的次数或者运行时间遥遥领先;这些都指向由于网络带宽所限导致的网络瓶颈。
    另外一种出现 Wait on condition的常见情况是该线程在 sleep,等待 sleep的时间到了时候,将被唤醒。
  4. locked:线程阻塞,是指当前线程执行过程中,所需要的资源长时间等待却一直未能获取到,被容器的线程管理器标识为阻塞状态,可以理解为等待资源超时的线程。
  5. Waiting for monitor entry 和 in Object.wait():Monitor是 Java中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者 Class的锁。
    每一个对象都有,也仅有一个 monitor。

你可能感兴趣的:(JVM,jvm,java)