jconsole工具使用

Jconsole，Java Monitoring and Management Console。

Jconsole是JDK自带的监控工具，在JDK/bin目录下可以找到。它用于连接正在运行的本地或者远程的JVM，对运行在java应用程序的资源消耗和性能进行监控，并画出大量的图表，提供强大的可视化界面。而且本身占用的服务器内存很小，甚至可以说几乎不消耗。

 

一、介绍

JConsole 是一个内置 Java 性能分析器，可以从命令行（直接输入jconsole）或在 GUI shell （jdk\bin下打开）中运行。

它用于对JVM中内存，线程和类等的监控。可使用JTop插件。它可以监控本地的jvm，也可以监控远程的jvm，也可以同时监控几个jvm。 

这款工具的好处在于，占用系统资源少，而且结合Jstat，可以有效监控到java内存的变动情况，以及引起变动的原因。在项目追踪内存泄露问题时，很实用。 

 

使用 JConsole 进行工作

分析器有自己的开销，因此最好的办法就是花点时间来弄清是什么开销。发现 JConsole 开销最简单的办法是，首先独自运行一个应用程序，然后在分析器下运行，并测量差异。（应用程序不能太大或者太小；我最喜欢使用 JDK 附带的 SwingSet2 样本。）因此，我使用 -verbose:gc 尝试运行 SwingSet2 来查看垃圾收集清理，然后运行同一个应用程序并将 JConsole 分析器连接到它。当 JConsole 连接好了之后，一个稳定的 GC 清理流出现，否则不会出现。这就是分析器的性能开销。

 

二、远程监控

因为 Web 应用程序分析工具假设通过一个套接字进行连通性分析，只需要进行少许配置来设置 JConsole（或者是基于 JVMTI 的分析器，就这点而言），监控/分析远程运行的应用程序。

远程监控与本地监控配置类似，这里以监控远程为例。

 

1、监控tomcat 

服务器端：

详细步骤如下所示：

1、  修改Tomcat的bin目录下的catalina.bat文件

vi catalina.sh

找到# OS specific support. $var _must_ be set to either true or false.添加如下变量： 

JAVA_OPTS="${JAVA_OPTS} -Djava.rmi.server.hostname=192.168.56.253 

-Dcom.sun.management.jmxremote.port=9999

-Dcom.sun.management.jmxremote.authenticate=true

-Dcom.sun.management.jmxremote.ssl=false

-Dcom.sun.management.jmxremote.acccess.file=/usr/local/tomcat/bin/jconsole/jmxremote.access

-Dcom.sun.management.jmxremote.password.file=/usr/local/tomcat/bin/jconsole/jmxremote.password"

注意：这里是一行，空格不合适可能会启动不了服务。

 

2、  切换用户到root，修改/etc/hosts添加IP地址。

添加如下信息： 
增加192.168.56.253 localhost 

Hostname -i

3、编辑jmxremote.access和jmxremote.password

这两个文件是在JDK里面的，可以通过%JAVA_HOME%/jre/lib/management目录找到。里面有个jmxremote.password.template文件，将其重命名为jmxremote.password，这就是控制远程连接的用户名密码的。

 

find . -name "jmxremote.password.template" -print ./usr/lib/jvm/java/jre/lib/management/jmxremote.password.template

$JAVA_HOME=/usr/lib/jvm/java/

 

#mkdir -p $JAVA_HOME/jconsole 
#cp $JAVA_HOME/jre/lib/management/jmxremote.password.template $JAVA_HOME/jconsole/jmxremote.password 
#cp $JAVA_HOME/jre/lib/management/jmxremote.access $JAVA_HOME/jconsole/jmxremote.access
修改文件权限： 
#chmod -R 600 jconsole 


此时提示错误: 必须限制口令文件读取访问: $JAVA_HOME/jconsole/jmxremote.password。 
解决办法：在$CATALINA_BASE（/tomcat/bin/）目录下新建jconsole文件夹，访问文件权限必须是600 
#mkdir -p $CATALINA_BASE/jconsole 
复制jmxremote.password、jmxremote.access到$CATALINA_BASE/jconsole,修改文件权限 
#chmod -R 600 jmxremote.password 
#chmod -R 600 jmxremote.access 

然后chmod对这两个文件赋权，600就可以了。

最后vi jmxremote.password,修改下面两行，把注释#去掉：

# monitorRole  XXXXXX
# controlRole  XXXXXX

 

 monitorRole  QED

 controlRole   R&D

 

4、  编辑 /etc/sysconfig/ iptables.old

增加一行：

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 9999 -j ACCEPT

COMMIT

 

查看端口是否被使用：netstat -apn|grep 9999

 

5、$CATALINA_BASE/bin/shutdown.sh.出现连接端口被占用提示。 
ps -ef | grep 1090 --被占用端口 
kill -9 pid 
重启Tomcat.$CATALINA_BASE/bin/startup.sh 
jconsole 远程连接（使用192.168.56.253:9999   controlRole R&D连接）

 

修改catalina.sh时，也可以将其设置为无密码访问，如：

 CATALINA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=192.168.116.111 
-Dcom.sun.management.jmxremote.port=9527 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false"

配置完并启动tomcat后，可使用netstat -ant|grep 9527端口（findstr "9527"）是否使用了，如果没使用则肯定配置没对。若启用了，则再确认下是否能连接上，监控项是否正确。

 

注意事项：

1、上边写的是修改catalina.bat，也可修改startup.sh或者如果是service服务来启动的，也可以直接加在startService.sh文件里。

2、无密码配置比较简单，如无必要不需要设置密码。

3、参数选项名称，“JAVA_OPTS=”若不行，可试试 "CATALINA_OPTS="

 

windows+tomcat8中，在catalina.bat中修改时，”JAVA_OPTS=“设置后，jconsole连接上看xmx这些参数与实际tomcat配置中的参数不同。后修改成了"CATALINA_OPTS="的形式，就连接配置正确的。

 

客户端：

已成功安装jdk1.5以上版本。在命令行下启动jconsole，选择远程进程，输入ip:port，用户名与密码，即可监控tomcat的jvm。

 

2、可能无法连接原因

从windows连接到linux时（centos5.4)时，老是连接不上）。原因是Linux上JVM给jconsole的RMI配置文件不对，
jvm使用了hostname -i的IP地址，我的/etc/hosts上127.0.0.1，所以远程老是连接不上。
只要在java启动参数中加入 -Djava.rmi.server.hostname=192.168.0.10  显示说明JVM返回给jconsole的IP地址即可。

JAVA_OPTS="-Xms256m -Xmx512m -XX:MaxPermSize=128m -Dcom.sun.management.jmxremote.port=1011 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=192.168.1.210"

 

 

2、监控was

http://xjsunjie.blog.51cto.com/999372/1331880

三、使用简介

当Jconsole连接成功后，它从JMX获取信息，我们便可以在里面监控具体的内容。
Jconsole能捕获到以下信息：

  1. 概述 － JVM概述和一些监控变量的信息
  2. 内存 － 内存的使用信息
  3. 线程 － 线程的使用信息
  4. 类 － 加载java类的信息
  5. VM － JVM摘要
  6. MBeans － 所有MBeans的信息

性能测试过程中需要关注哪些信息呢？一般主要关注内存栏、线程栏、类栏，概述栏和VM栏次之，MBeans栏在追踪具体问题时用到。

 

随时可以使用JConsole的在右上角的绿色连接状态图标，断开或重新连接到正在运行的Java虚拟机。 从下拉菜单中选择连接，然后新建连接，您可以同时连接到任何数量运行中的Java虚拟机。

以下以本地监控jconsole进程为例讲解。

1、 查看概述信息

概述选项卡中显示CPU使用率，内存使用率，线程数，Java VM中加载的类的监控信息。

图3-1概述“选项卡

 

JConsole的概述标签

“概述”选项卡提供了一种简单的方法相关的信息，以前只能通过多个选项卡之间切换。

保存图表数据

JConsole的，可以让您保存在一个逗号分隔值（CSV）文件中的图表提供的数据。 为了节省从图表中的数据，只需右键单击任何图表上， 选择保存数据，然后指定其中的数据将被保存的文件。 从任何任何JConsole的不同的标签以这种方式显示的图表，您可以保存数据。

CSV格式是常用的电子表格应用程序之间的数据交换。 CSV文件可以导入到电子表格应用程序，可以用来创建这些应用程序的图表。 这些数据是两个或多个命名的列，第一列表示的时间戳。 导入电子表格应用程序的文件后，你通常需要选择的第一列，并改变其格式为“日期”或“日期/时间”。

 

2、监控内存消耗

Memory选项卡提供了内存消耗和内存池的信息。

图3-2内存“选项卡

JConsole的内存选项卡。

 

图3-3内存“选项卡

 

图3-2，3-3显示都没有问题，只是监控的进程不同而有所区别。非堆内存显示区域不同。

内存标签功能“执行GC”的按钮，可以单击执行垃圾收集。 图表动态显示内存使用的堆和非堆内存的内存池。 可用的内存池取决于正在使用的版本的Java VM。 串行垃圾回收的内存池的HotSpot Java虚拟机，有以下几种。

  • 伊甸园空间（堆）：大多数对象最初分配内存的池。
  • 生存空间（堆）：包含伊甸园空间垃圾收集后生存的对象。
  • 年老代（堆）：池包含已经存在一段时间的对象。
  • 永久代（非堆）：池包含的所有虚拟机本身的反射的数据，如类和方法的对象。 Java虚拟机，使用类数据共享，这一代分为只读和读写区域。
  • 代码缓存（非堆）：HotSpot Java虚拟机的还包括一个代码缓存，包含内存，使用本机代码的编译和存储。

可以从图表下拉菜单中的选项选择不同的图表显示图表这些内存池的消费。 此外，点击在右下角的角落堆和非堆图标，将切换显示图表（与下拉框选择不同类型图表功能相同）。 最后，可以指定跟踪内存使用情况，从时间范围内的下拉菜单中的选项选择的时间范围。

欲了解更多有关这些内存池的信息，请参阅下面的垃圾收集。

“详细信息”区域显示了当前内存信息：

  • 已使用：目前使用的内存量，包括所有对象，可达和不可达占用的内存。
  • 分配 ：保证由Java虚拟机使用的内存量。 提交的内存量可能会随时间而改变。 Java虚拟机可能会释放系统内存，并已提交的内存量可能会少于最初启动时分配的内存量。 提交的内存量将始终大于或等于使用的内存量。
  • 最大值，可用于内存管理的最大内存量。 它的价值可能会发生变化，或者是不确定的。 如果Java虚拟机试图增加使用的内存要大于提交的内存，内存分配可能失败，即使使用量小于或等于最大值（例如，当系统上的虚拟内存不足）。
  • GC时间 ：累计时间花在垃圾收集和调用的总数。 它可能有多个行，其中每一个代表一个垃圾收集器算法在Java虚拟机使用时间。
    MarkSweepCompact：年轻代GC
    Scavenge：full GC

GC时会暂停整个JAVA应用，普通GC 只是对年轻代进行垃圾回收，full的GC会对整个堆内存（包含老年代、年轻代）进行垃圾回收。system的GC显示调用GC。

full gc 只会在两个情况下发生：1）system.gc被显示调用时，会执行full gc。2）老年代的堆内存满时，会执行full gc。
 

较低的右侧的条形图显示堆和非堆内存中的内存池消耗的内存。 列会变成红色时，使​​用的内存超过了内存使用阀值。

堆和非堆内存

Java虚拟机管理两种内存：堆和非堆内存，这两者都是Java虚拟机启动时创建的。

  • 堆内存是运行时数据区域，Java VM的所有类实例和数组分配内存。 可能是固定或可变大小的堆。
  • 非堆内存包括在所有线程和Java虚拟机内部处理或优化所需的共享的方法。 它存储了类的结构，运行常量池，字段和方法数据，以及方法和构造函数的代码，方法区在逻辑上是堆的一部分，看具体实现的方式。根据实现方式的不同，Java虚拟机可能不进行垃圾收集或压缩。 堆内存一样，方法区域可能是一个固定或可变大小。 方法区的内存不需要是连续的。

除了方法区，Java虚拟机可能需要进行内部处理或优化，这也属于非堆内存的内存。 例如，实时（JIT）编译器需要内存用于存储从Java虚拟机的高性能的代码翻译的机器码。

 

内存池和内存管理器

内存池和内存管理器是Java虚拟机的内存系统的关键环节。

  • 一个内存池表示Java虚拟机管理的内存区域。 Java虚拟机至少有一个内存池，它可能在执行过程中创建或删除内存池。 一个内存池可以属于堆或以非堆内存。
  • 一个内存管理器管理一个或多个内存池。 垃圾收集器是一个负责回收不可达的对象使用的内存的内存管理器。 Java虚拟机可能有一个或更多的内存管理器。 在执行过程中，它可以添加或删除内存管理器。 一个内存池可以由一个以上的内存管理器进行管理。

垃圾收集

垃圾收集（GC）是Java虚拟机如何释放不再被引用的对象所占用的内存。 它通常认为的对象，有作为“活着”和非引用作为或不可达对象的活动引用“死。” 垃圾收集是由死对象占用的的内存释放过程。 气相色谱法的算法和使用的参数可以对性能有巨大影响。

Java HotSpot虚拟机的垃圾收集器使用代GC。 代GC的优势，大多数都符合以下的概括。

  • 他们创建有许多短暂的一生对象，例如，迭代和局部变量。
  • 他们创建一些对象，有很长的生活，例如，高层次的持久对象。

代GC分为几代，并给每个指定一个或多个内存池。 当一代使用了分配的内存，虚拟机上执行一个局部的GC（也叫minor collection），内存池回收死对象使用的内存。 这部分的GC速度通常远远优于一个完整的GC。

Java HotSpot虚拟机定义了两代：年轻代（有时也被称为“托儿所”）和年老代。 年轻代包括“伊甸园空间”和两个“生存空间”。 最初，VM将所有的对象在“伊甸园”空间，大多数对象死在那里。 当它执行了一次minor GC，VM将剩余的对象从“伊甸园空间”转移到“生存空间”。 虚拟机将足够长生存时间的对象移动到年老代的空间。 当年老代填满了，将是一个完整的GC，往往是慢得多，因为它涉及到所有存活的对象。 永久代包含所有的虚拟机本身的反射，如类和方法的对象的数据。

默认情况下代安排看起来像图3-4。

图3-4代的数据，在垃圾收集

不同世代的数据定义由垃圾回收器

如果垃圾收集器已经成为一个瓶颈，你可以通过自定义代大小来提高性能。 使用JConsole，你可以调查你的性能指标的敏感性实验与垃圾收集器的参数。 欲了解更多信息，请参阅调整与5.0 HotSpot虚拟机的垃圾收集，http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html。

3、监视线程使用

线程“选项卡上提供了有关线程使用的信息。

图3-5 Threads选项卡

JConsole的主题卡。

在左下角的“线程”列表列出了所有的活动线程。 如果你输入一个“过滤器”字段中的字符串，线程列表将只显示其名称中包含你输入字符串线程。 点击一个线程在线程列表的名称，显示该线程的信息的权利，包括线程的名称，状态、阻塞和等待的次数、堆栈跟踪。

图表显示活动线程的数量随着时间的推移。 两行显示。

  • 红色 ：峰值线程数
  • 蓝 ：活动线程数。

线程选项卡提供了几个有用的操作。

  • findMonitorDeadlockedThreads：检测，如果任何线程对象监视器锁定陷入死锁。 此操作返回一个死锁的线程ID数组。
  • getThreadInfo：返回线程的信息。 这包括名称，堆栈跟踪和监测锁，该线程目前已封锁，如果有的话，哪个线程持有该锁，以及线程争用统计。
  • getThreadCpuTime：返回给定的线程所消耗的CPU时间

通过MBeans选项卡，您可以通过选择的MBean树中的线程MXBean的这些附加功能。 这MXBean的访问被监视的Java虚拟机线程信息列出所有的属性和操作。 请参阅监视和管理的 MBean 。

检测死锁线程

要检查如果您的应用程序已经陷入了僵局运行（例如，您的应用程序似乎是挂了），死锁的线程可以通过点击“检测死锁”按钮检测。 如果检测到任何死锁的线程，这些都显示在一个新的标签，旁边出现的“主题”标签， 在图 3-6所示。

图3-6僵持主题

JConsole的死锁线程检测。

检测死锁“按钮，将涉及对象监视器和 java.util.concurrent的可拥有同步器（见API 规范文档java.lang.management.LockInfo）检测死锁循环。 Java SE 6中已加入的java.util.concurrent锁的监控支持。 如果JConsole的连接到一个J2SE 5.0 VM，检测死锁机制只会找到相关的对象监视器死锁。 jconsole会不显示任何相关的可拥有同步器的死锁。

关于线程和守护线程的详细信息， 请参见API文档的java.lang.Thread。

 

4、监视类载入中

“类”标签显示关于类加载的信息。

图3-7类标签

图表曲线加载的类的数量随着时间的推移。

  • 红线总数（包括后来卸载的）加载的类。
  • 蓝线是当前的类加载。

在选项卡底部的详细信息部分显示类的加载，因为Java虚拟机开始的总数，当前加载和卸载的数量。 跟踪类加载详细的输出，您可以勾选在顶部的右上角复选框。

查看VM信息

VM摘要“选项卡提供了对Java虚拟机的信息。

图3-8虚拟机摘要选项卡

JConsole的VM摘要“选项卡。

在此选项卡中提供的信息包括以下内容。

  • 摘要
    • 运行时间 ：开始以来，Java虚拟机的时间总额。
    • 进程的CPU时间 ：Java VM的开始，因为它消耗的CPU时间总量。
    • 编译总时间 ：累计时间花费在JIT编译。
  • 主题
    • 活动线程 ：目前现场守护线程，加上非守护线程数量。
    • 峰值 ：活动线程的最高数目，因为Java虚拟机开始。
    • 守护线程 ：当前的活动守护线程数量。
    • 总线程 ：开始自Java虚拟机启动的线程总数，包括非守护进程，守护进程和终止的线程。
  • 类
    • 当前类装载 ：目前加载到内存中的类数目。
    • 总类加载 ：从Java VM开始加载到内存中的类总和，包括那些后来被卸载的类。
    • 已卸载类总数 ：从Java虚拟机开始从内存中卸载的类的数目。
  • 内存
    • 当前的堆大小 ：目前所占用的堆的千字节数。
    • 分配的内存 ：堆分配的内存总量。
    • 最大堆最大值 ：堆所占用的千字节的最大数目。
    • 待最后确定的对象：待最后确定的对象的数量。
    • 花在执行GC的垃圾收集器 ：包括垃圾收集，垃圾收集器的名称，进行藏品的数量和总时间的信息。
  • 操作系统
    • 总物理内存
    • 空闲物理内存
    • 分配的虚拟内存
  • 其他信息
    • VM参数 ：输入参数的应用程序通过Java虚拟机，不包括的主要方法的参数。
    • 类路径是由系统类加载器用于搜索类文件的类路径。
    • 库路径 ：加载库时要搜索的路径列表。
    • 引导类路径 ：引导类路径是由引导类加载器用于搜索类文件。

 

5、监控和​​管理的MBean

MBeans选项卡显示的信息平台MBean服务器中的一个通用的方法对所有已注册的MBean。 MBeans选项卡允许您访问平台MXBean。 此外，您还可以监控和管理您的应用程序的MBean。

图3-9 MBeans选项卡

JConsole的MBeans选项卡。

左侧的树显示当前正在运行的所有MBean。 当您选择树中的一个MBean， 其 MBeanInfo及其MBean描述符都显示在右侧，并在它下面的树中出现的任何属性，操作或通知。

所有平台MXBean和各种操作和属性是通过JConsole的MBeans选项卡访问。

构建MBean的树

默认情况下，基于对象的名称树中示MBean。jconsole会使用确切的键属性列表构建MBean树，构建时调用ObjectName.getKeyPropertyListString（）方法返回类型的第一个key，和j2eeType的第二个key，如果存在的话。

然而，依靠ObjectName的关键属性的默认顺序，有时可以导致意外的结果。例如，如果两个对象的名字也有类似的key，但其key的排序不同，那么相应的MBean将不会在MBean树相同的节点下创建。

例如，假设您创建具有下列名称的三角MBean的对象。

com.sun.example:type=Triangle,side=isosceles,name=1
com.sun.example:type=Triangle,name=2,side=isosceles
com.sun.example:type=Triangle,side=isosceles,name=3

至于JMX技术而言，这些对象将被视为在完全一样的方式。在对象名称的键的顺序不作任何JMX技术的差异。但是，如果JConsole连接这些MBean，并使用默认的MBean树渲染，那么对象com.sun.example：type=Triangle，name=2，side=isosceles最终会被节点Triangle下创建，在一个节点2，将包含一个子节点称为isosceles。其他两个isosceles，name= 1 name= 3，将分设在不同的节点isosceles下，如图3-10所示。

图3-10意外的MBean树渲染范例

意外的MBean树渲染示例

您可以指定MBean提供一个有序的键属性列表来避免这个问题。当你在命令行启动JConsole时，通过设置系统属性com.sun.tools.jconsole.mbeans.keyPropertyList:

% jconsole -J-Dcom.sun.tools.jconsole.mbeans.keyPropertyList=key[,key]*

键属性列表需要一个逗号分隔，在您所选择的， key的地方必须是一个字符串，代表一个对象的名称键或一个空字符串的顺序。 如果在列表中指定的一个key并不适用于一个特定的MBean，那么该key将被丢弃。bjectName.getKeyPropertyListString（）返回值定义的键的顺序，将用于完成 keyPropertyList定义的键顺序。 因此，指定一个空的键列表仅仅意味着jconsole会显示MBean的ObjectName的键。

因此，返回到上面提到的例子，你可以选择指定的keyPropertyList系统属性启动JConsole:

% jconsole -J-Dcom.sun.tools.jconsole.mbeans.keyPropertyList=side,name

JConsole中会产生的MBean树如图 3-11所示。

图3-11范例的MBean树构造使用keyPropertyList

MBean的树的例子建造使用keyPropertyList

在图3-10中，side第一，name第二。 因为type不是在指定的键属性列表类型的key，因此MBean树算按默认次序排序。

根据公约所定义的JMX最佳实践准则的对象的名称， 类型的关键应该永远是第一位的。 因此，要尊重本公约应从以下系统属性JConsole的。

 ％JConsole的- J - Dcom.sun.tools.jconsole.mbeans.keyPropertyList =type,side,name

上面的命令将导致JConsole的渲染如图3-12中所示

图3-12范例的MBean树尊重JMX的最佳实践构建

MBean的树的例子构筑尊重JMX的最佳实践

这显然远远超过难理解的图3-10和图3-11中显示的MBean的树。

MBean属性

选择“属性”节点显示一个MBean的所有属性，图3-13显示了Threading的所有属性。

图3-13查看所有的MBean属性

查看线程的MBean的属性。

选择单个MBean属性, 其 MBeanAttributeInfo，会显示在右窗格中，如图3-14。

图3-14查看单个的MBean属性

查看MBean属性的MBean标签。

您可以通过双击右侧窗体中粗体文本显示更多信息。 例如，如果你点击HeapMemoryUsage 对应的value值，你会看到一个图表：图3-15 。

图3-15显示的属性值

查看MBean属性值。

双击数字属性值将显示一个图表，图，数值的变化。 例如，双击上的垃圾收集器的MBean 的PS Marksweep CollectionTime属性，将显示执行垃圾收集所花费的时间。

您还可以使用JConsole设置可写属性的值。 一个可写的属性的值显示为蓝色。 在这里你可以看到内存的MBean的详细属性。

图3-16设置可写的属性值

设置一个MBean的可写属性的值。

您可以通过点击，然后编辑它们的属性。 例如，启用或禁用在JConsole详细的垃圾收集器跟踪，选择在MBeans选项卡的MXBean 和详细的属性设置为真或假。 同样，类加载的MXBean也有详细的属性，可以设置启用或禁用类加载的详细跟踪。

MBean操作

选择“操作”节点显示一个MBean的所有操作。你可以通过按钮去调用方法. 图3-20 所有线程的方法。

Figure 3-17 Viewing All MBean Operations

Viewing the Threading platform MXBean's operations.

选择一个MBean树中选择一个方法，可以看到该方法的描述信息，如图 3-18 .

Figure 3-18Viewing Individual MBean Operations

Invoking an MBean's operations.

MBean通知

在左边的树中选择订阅，并点击订阅按钮。右侧将显示收到的通知。如图3-19。

Figure 3-19 Viewing MBean Notifications

Viewing an MBean's notifications.

选择单个MBean通知，MBeanNotificationInfo会显示在右窗格中，如图3-20所示。

Figure 3-20 Viewing Individual MBean Notifications

Subscribing to receive MBean Notifications.

HotSpot的诊断的MXBean

JConsole的MBeans选项卡还允许你告诉HotSpot虚拟机执行堆转储，并通过HotSpotDiagnostic MXBean的VM选项，以获取或设置。

Figure 3-21 Viewing the HotSpot Diagnostic MBean

Performing heap dumps using the HotSpot VM Diagnostic MBean.

 

Figure 3-22 Viewing the HotSpot Diagnostic MBean

您可以手动执行堆转储调用com.sun.management.HotSpotDiagnostic MXBean的dumpheap命令操作。此外，您可以指定HeapDumpOnOutOfMemoryError Java VM选项，使用setVMOption操作，因此，VM执行堆转储时自动收到一个OutOfMemoryError。

 

创建自定义选项卡

除了现有的标准选项卡，你可以添加自己的自定义选项卡JConsole的，执行自己的监视活动。 JConsole的插件API提供了一种机制，例如，通过它可以添加标签来访问自己的应用程序的MBean。 JConsole这样的插件API定义com.sun.tools.jconsole.JConsolePlugin抽象类，你可以扩展到建立您的自定义插件。

如上所述，您的插件必须继承JConsolePlugin，并实现JConsolePlugin getTabs和newSwingWorker方法。 getTabs方法返回的选项卡的列表被添加到JConsole的，或者一个空列表。 newSwingWorker方法返回SwingWorker的负责插件的GUI更新。

您的插件必须提供一个Java归档（JAR）的文件，该文件包含一个名为META-INF/services/com.sun.tools.jconsole.JConsolePlugin文件。这个JConsolePlugin文件本身包含的所有插件完全合格的类名要添加新JConsole的标签列表。 JConsole中使用的服务提供商的装卸设施，来查找并加载插件。你可以有多个插件。
要加载到JConsole的新的自定义插件，启动JConsole的用下面的命令：

%  jconsole -pluginpath plugin-path

在上面的命令，插件路径指定要查找的JConsole插件的路径。这些路径可以是目录名或JAR文件，并可以指定多个路径，用你的平台的标准分隔符字符。

一个例子JConsole的插件提供了Java SE 6平台。 JTop应用程序是JDK的演示，展示了在应用程序中运行的所有线程的CPU使用率。这个演示是有用的识别，具有较高的CPU消耗的线程，它已被更新作为一个JConsole的插件以及一个独立的GUI使用。 JTop是捆绑在一起的Java SE 6平台，作为一个演示应用程序。您可以运行的JTop插件JConsole中运行以下命令：

%JDK_HOME/bin/jconsole -pluginpath JDK_HOME/demo/management/JTop/JTop.jar

如果您连接到这种JConsole的实例，你会看到，JTop标签已被添加，显示运行各个线程的CPU使用率。

Figure 3-25 Viewing a Custom Plug-in Tab

A custom tab showing connected to the JTop example program.

 

 

参考：

1、http://www.ibm.com/developerworks/cn/java/j-5things7.html?ca=drs-

2、http://zhumeng8337797.blog.163.com/blog/static/1007689142012424114643418/

3、jconsole使用参考：http://hornetblog.sinaapp.com/?p=5

http://www.open-open.com/lib/view/open1345646982251.html 

Jconsole与Jmx 分析JVM状况

 

posted @ 2014-03-26 14:20  milkty  阅读(17688)  评论(1)  编辑  收藏  举报