windows下监控和分析java进程

1、利用任务管理器或者 jps 命令找到我的程序的进程ID

  在cmd控制台下输入jps命令,即可列出当前电脑运行的java程序的所有进程,我的程序的进程ID为26028

2、利用 jstack 命令列出进程的所有信息

这里写图片描述

  使用命令jstack 26028 > 26028.txt列出进程ID为26028的进程信息,并输出到26028.txt文本文件中。 
  之后打开这个文件可以看到当前进程的所有线程信息,包括线程的状态、线程的ID号以及堆栈信息等。 
  在文件的最后,我们会看到几个负责GC的线程,nid就是线程的ID:

 

3、使用 pslist 工具查看进程的所有线程的详细信息

  在cmd控制台输入pslist,如果命令不被识别,则表示当前电脑上没有安装pslist这个工具,可以到windows官方网站: 
https://technet.microsoft.com/en-us/sysinternals/bb896682.aspx下载,下载完成后将其解压到C:\Windows\System32路径下即可使用,或者将其配置到环境变量中亦可。

  安装完成后,使用pslist -dmx 26028 > 26028_pslist.txt命令,可以列出进程ID为26028的进程下的所有线程的详细信息(线程ID、上下文切换,状态等)。

这里写图片描述

  打开输出的文件,可以看到:

这里写图片描述

  从这个文件所列的信息中,我们可以找到最耗资源的线程。然后将其Tid(线程ID)转换成十六进制(直接利用windows下的计算器即可),到使用jstack命令产生的文件中查找,可以查到具体哪一个线程在干什么,为什么这么耗资源?


  最后,我发现我的程序最耗资源的线程是所有GC线程,而程序中我的工作线程基本上都处于阻塞状态(以上截图并没有体现,进程26028是正常运行时我截的图)。那么为什么GC这么耗资源呢?一开始我认为是哪一个资源忘记释放了,于是我将打开的字节流、socket资源等都确认关闭了一遍。可是重新运行程序4、5个小时之后依然出现了同样的问题。显然问题并没有解决。


4、jmap+MAT分析

  MAT工具的安装以及使用,网上有很多资料,这里就不做赘述了。

  运行程序,当问题出现时,使用jmap指令将内存dump到文件,命令是:jmap -dump:format=b,file=jmap.bin 26028.

  然后使用MAT工具加载该dump文件即jmap.bin,进行分析。

  最后发现有一种数据库连接对象在内存中积累,占据了将近3G的内存,奇怪的是这段代码我在很多程序中复用过,都没有出现过问题。所以我判断应该是由于高并发造成的问题,数据库可能承受不了这么大的压力。

  我将存入数据库的代码先注释掉,改成存储到文件之后,就一切正常了。

  好了,bug是找到了,接下来我该去看看高并发的数据库设计了。


接下来我再介绍调bug过程中用到的几款工具。

5、jconsole jvisualvm 工具

  这两个工具都是JDK自带的监控java程序的工具,可以监控本地进程和远程进程。jvisualvm提供的信息更多一点。 
  直接在cmd控制台输入jconsolejvisualvm就可以调出这两个工具。 
jconsole的界面如下:

这里写图片描述

Jvisualvm (JDK1.6+):界面如下:

6、windows提供的 process explorer 工具

  该工具可以到网上下载,它提供比任务管理器更详细的进程信息,并且可以查看每个进程下的线程:

这里写图片描述

这里写图片描述

 

posted @ 2019-04-29 17:14  myseries  阅读(5783)  评论(0编辑  收藏  举报