使用JCONSOLE远程监控JVM

时间 2020-07-17

原文原文链接

启动JMS服务

JConsole是从Java 5中开始引入的一个用于对JVM性能和资源消耗进行监控的图形化工具。
JConsole能够链接本地的Java程序，也能够链接远程的Java程序。因为是GUI的方式使用，因此就不细说那些基本的使用方法了，这里只是记录一下试用过程当中遇到的几个小问题及其解决方案。html

1. 要实现让JConsole能够远程链接到某个Java程序，则须要在Java程序启动的JAVA_OPTION中添加选项“com.sun.management.jmxremote.port=8888”来指定远程管理的端口。java

2. 启动Java程序时，遇到以下报错：算法

Thu Jul 25 23:00:50 CST 2013
 
./jbb.jar:./check.jar:
java full version "1.6.0_24-b24"
Error: Password file not found: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/management/jmxremote.password
Thu Jul 25 23:00:50 CST 2013

这是因为开启Java JMX 远程管理时，默认会有用户名密码的验证，因此须要相应的密码文件。shell

[root@localhost SPECjbb2005]# ls /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/management/
jmxremote.access  jmxremote.password.template  management.properties  snmp.acl.template

须要先在jmxremote.access中定义用户权限，而后在jmxremote.password文件中定义用户名和对应的密码，jmxremote.password文件能够复制jmxremote.password.template模板文件来进行修改。
固然，在内网中仅仅用于调试，咱们通常能够不设置密码验证和SSL链接方式，Java选项以下：
-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false数组

报错：缓存

Error: Password file read access must be restricted: /usr/java/jdk1.8.0_60/jre/lib/management/jmxremote.password

在配置JMX远程访问的时候，设置jmxremote.password文件权限，修改该文件时添加写权限，chmod +w jmxremote.password ，放开角色信息那俩行的注释，保存，再使用chmod 0400 jmxremote.password服务器

这样就是它正确的权限设置oracle

jmxremote.password 在jdk/jre/lib/management/下，jmxremote.password.template复制，去掉.template后缀jvm

3. 在进行了端口和认证信息的配置后，发如今JConsole中经过IP远程链接JVM依然不成功。
错误信息为：Connection Failed: Retry? The connection to 192.168.52.11:8888 did not succeed. Would you like to try again?
在启动Java时，须要设置RMI远程调用的主机名，通常设置为主机的IP地址便可，以下：
-Djava.rmi.server.hostname=192.168.52.11
（固然，也有多是因为前面第2点中提到的SSL的设置问题，依然须要检查一下）ide

关于JConsole，仍是得执行看看Oracle的这篇Java SE 6 中的JConsole的描述：
http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html
（特别是上面文档中对监控数据、图形表明的意义是须要认真理解的）

Using JConsole

JConsole图形用户界面是符合Java Management Extensions（JMX）规范的监视工具。JConsole使用Java虚拟机（Java VM）的大量工具来提供有关在Java平台上运行的应用程序的性能和资源消耗的信息。

在Java平台标准版（Java SE平台）6中，JConsole已更新，以呈现Windows和GNOME桌面的外观（其余平台将呈现标准的Java图形外观）。本文档中提供的屏幕截图取自在Windows XP上运行的界面实例。

Starting JConsole

jconsole可执行文件能够在JDK_HOME / bin中找到，其中JDK_HOME是Java开发工具包（JDK）的安装目录。若是此目录位于系统路径中，则只需在命令（shell）提示符下键入jconsole便可启动JConsole。不然，您必须输入可执行文件的完整路径。

Command Syntax

您可使用JConsole监视本地应用程序，即与JConsole在同一系统上运行的应用程序，以及远程应用程序，即在其余系统上运行的应用程序。

注 - 使用JConsole监视本地应用程序对于开发和建立原型很是有用，但不建议在生产环境中使用，由于JConsole自己会消耗大量的系统资源。建议使用远程监控将JConsole应用程序与正在监控的平台隔离。

有关jconsole命令的语法的完整参考，请参阅jconsole命令的手册页：Java监视和管理控制台。 Java Monitoring and Management Console.

Setting up Local Monitoring

Setting up Remote Monitoring

要启动JConsole进行远程监视，请使用如下命令语法:

% jconsole hostName:portNum

在上面的命令中，hostName是运行应用程序的系统的名称，portNum是您在启动Java VM时启用JMX代理时指定的端口号。有关更多信息，请参阅远程监视和管理。

若是您未指定主机名/端口号组合，则JConsole将显示链接对话框（链接到JMX代理），以便您输入主机名和端口号。

Viewing Overview Information

“Overview”（概览）选项卡显示关于CPU使用状况，内存使用状况，线程数量以及Java VM中加载的类的图形化监视信息，全部这些都在一个屏幕中显示。

“概览”选项卡提供了一种简单的方法，能够关联以前仅经过在多个选项卡之间切换才可用的信息。

Saving Chart Data

JConsole容许您将图表中显示的数据保存为逗号分隔值（CSV）文件。要保存图表中的数据，只需右键单击任意图表，选择保存数据为...，而后指定将保存数据的文件。您能够经过这种方式保存JConsole不一样选项卡中显示的任何图表中的数据。

CSV格式一般用于电子表格应用程序之间的数据交换。CSV文件能够导入到电子表格应用程序中，并可用于在这些应用程序中建立图表。数据以两个或多个命名列显示，其中第一列表明时间戳。将文件导入电子表格应用程序后，一般须要选择第一列，并根据须要将其格式更改成“日期”或“日期/时间”。

Monitoring Memory Consumption

“内存”选项卡提供有关内存消耗和内存池的信息。

“内存”选项卡具备“执行GC”按钮，您能够随时单击执行垃圾回收。该图表显示了随时间变化的Java VM的内存使用状况，堆内存和非堆内存以及特定内存池的使用状况。可用的内存池取决于正在使用哪一个版本的Java VM。对于HotSpot Java VM，用于串行垃圾收集的内存池以下所示：

Eden Space (heap): 内存最初分配给大多数对象的池。

Survivor Space (heap): 包含在伊甸园空间的垃圾收集中存活的对象的池。

Tenured Generation（heap）：包含已经存在一段时间的幸存者空间中的对象的池。

Permanent Generation (non-heap):包含虚拟机自己的全部反射数据（例如类和方法对象）的池。使用类数据共享的Java虚拟机，这一代分为只读和读写区域。

Code Cache (non-heap): HotSpot Java VM还包含代码缓存，其中包含用于编译和存储本机代码的内存。

您能够经过选择“图表”下拉菜单中的选项来显示不一样的图表，以绘制这些内存池的消耗状况。此外，单击右下角的堆或非堆图条会切换显示的图表。最后，您能够经过从“时间范围”下拉菜单中的选项中进行选择来指定跟踪内存使用状况的时间范围。

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

“详细信息”区域显示多个当前内存指标：

Used：当前使用的内存量，包括全部对象占用的内存，可达到和不可达。

Committed：保证可供Java VM使用的内存量。提交的内存量可能随时间而改变。Java虚拟机可能会向系统释放内存，而且提交的内存量可能会少于启动时初始分配的内存量。提交的内存量老是大于或等于已用内存量。

Max：可用于内存管理的最大内存量。它的值可能会改变或者是未定义的。若是Java虚拟机尝试增长使用的内存大于提交的内存，即便使用的数量小于或等于最大值（例如，当系统虚拟内存不足时），内存分配也可能会失败。

GC time：垃圾收集的累积时间和总调用次数。它可能有多行，每行表明Java VM中使用的一个垃圾收集器算法。

右下角的条形图显示了堆和非堆内存中的内存池使用的内存。当使用的内存超过内存使用阈值时，条形会变成红色。您能够经过MemoryMXBean的属性设置内存使用率阈值。

Heap and Non-Heap Memory

Java VM管理两种内存：堆和非堆内存，这两种内存都是在Java VM启动时建立的：

　　堆内存是Java VM为其分配全部类实例和数组的内存的运行时数据区域。堆能够是固定的或可变的大小。垃圾收集器是一个自动内存管理系统，为对象回收堆内存。

　　非堆内存包括在Java VM的内部处理或优化所需的全部线程和内存之间共享的方法区。它存储每类结构，如运行时常量池，字段和方法数据以及方法和构造函数的代码。方法区域在逻辑上是堆的一部分，但根据实现，Java VM可能不会垃圾收集或压缩。像堆内存同样，方法区域能够是固定或可变的大小。方法区域的内存不须要是连续的。

　　除了方法区域以外，Java VM可能须要内存来进行内部处理或优化，这也属于非堆内存。例如，即时（Just-In-Time，JIT）编译器须要内存来存储从Java VM代码转换来的高性能的本地机器代码。

Memory Pools and Memory Managers

内存池和内存管理器是Java VM内存系统的关键方面。

内存池表示Java VM管理的内存区域。Java虚拟机至少有一个内存池，它可能会在执行期间建立或删除内存池。内存池能够属于堆或非堆内存。

内存管理器管理一个或多个内存池。垃圾回收器是一种内存管理器，负责回收不可达对象所使用的内存。Java VM可能有一个或多个内存管理器。它可能会在执行期间添加或删除内存管理器。一个内存池能够由多个内存管理器来管理。

Garbage Collection

垃圾收集（GC）是Java VM如何释放再也不被引用的对象占用的内存。一般将具备活动引用的对象视为“活着”，而且将不引用（或不可访问）的对象视为“死亡”。垃圾收集是释放死对象所使用的内存的过程。GC使用的算法和参数可能会对性能产生显着影响。

Java HotSpot VM垃圾收集器使用分代GC。世代GC利用了大多数程序符合如下归纳的观察：

　　他们建立了不少寿命很短的对象，例如迭代器和局部变量。

　　他们建立了一些具备很长生命的对象，例如高级持久对象。

分代GC将内存分红几代，并为每一个分配一个或多个内存池。当一代人使用其分配的内存时，VM会在该内存池上执行部分GC（也称为次要集合）来回收死对象所使用的内存。部分GC一般比FULL GC快得多。

Java HotSpot虚拟机定义了两代：年轻一代（有时称为“托儿所”）和老一代。年轻一代包括一个"Eden space"和两个"survivor spaces."。VM最初将全部对象分配到Eden空间，大多数对象都在那里死掉。当它执行一个次要的GC时，虚拟机将全部剩余的对象从Eden空间移动到其中一个幸存者空间。虚拟机将生存空间足够长的物体移动到老一代的“终身”空间。当终身代填满时，有一个完整的GC一般要慢得多，由于它涉及全部的活物。永久生成包含虚拟机自己的全部反射数据，例如类和方法对象。

世代的默认排列如图3-7所示：

若是垃圾收集器已成为瓶颈，则能够经过自定义生成大小来提升性能。使用JConsole，您能够经过尝试使用垃圾收集器参数来调查性能指标的敏感性。有关更多信息，请参阅使用5.0 HotSpot VM调整垃圾回收。

Monitoring Thread Use

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

左下角的线程列表列出了全部活动的线程。若是在“过滤器”字段中输入字符串，则“线程”列表将仅显示名称中包含您输入的字符串的线程。单击“线程”列表中线程的名称可显示有关该线程的信息，包括线程名称，状态和堆栈跟踪。

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

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

线程MXBean提供了线程选项卡未涵盖的其余几个有用的操做。

findMonitorDeadlockedThreads：检测是否有任何线程在对象监视器锁上死锁。该操做返回一个死锁的线程ID数组。

getThreadInfo：返回线程信息。这包括线程当前被阻塞的名称，堆栈跟踪和监视器锁，以及哪一个线程持有该锁，以及线程争用统计信息。

getThreadCpuTime：返回给定线程消耗的CPU时间

经过在MBeans树中选择Threading MXBean，能够经过MBeans选项卡访问这些附加功能。这个MXBean列出了在被监控的Java VM中访问线程信息的全部属性和操做。请参阅监视和管理MBean。

Detecting Deadlocked Threads

要检查你的应用程序是否已经遇到死锁（例如，你的应用程序彷佛挂起），能够经过单击“检测死锁”按钮来检测死锁的线程。若是检测到任何死锁的线程，则会显示在“线程”选项卡旁边的新选项卡中，如图3-9所示。

“检测死锁”按钮将检测涉及对象监视器和java.util.concurrent可拥有同步器的死锁周期（请参阅java.lang.management.LockInfo的API规范文档）。在Java SE 6中添加了对java.util.concurrent锁的监视支持。若是JConsole链接到J2SE 5.0 VM，则Detect Deadlock机制将仅查找与对象监视器相关的死锁。JConsole不会显示与可拥有的同步器相关的任何死锁。

有关线程和守护进程线程的更多信息，请参阅java.lang.Thread的API文档。

Monitoring Class Loading

类选项卡显示有关类加载的信息。

图表绘制了随着时间的推移加载的类的数量。

红线是加载的类的总数（包括随后卸载的类）。

蓝线是当前加载的类的数量。

选项卡底部的“详细信息”部分显示自Java VM启动以来加载的类的总数，当前加载的编号和卸载的编号。您能够经过选中右上角的复选框来将类加载的跟踪设置为详细输出。

Viewing VM Information

“VM摘要”选项卡提供有关Java VM的信息。

此选项卡中显示的信息包括如下内容。

Summary

正常运行时间：Java VM启动以来的总时间。

进程CPU时间：Java VM自启动以来消耗的CPU时间总量。

总编译时间：在JIT编译中花费的总时间。Java VM肯定什么时候发生JIT编译。Hotspot虚拟机使用自适应编译，其中VM使用标准解释器启动应用程序，而后在运行时分析代码以检测性能瓶颈或“热点”。

Threads

活动线程：活动守护程序线程的当前数量加上非守护程序线程。

峰值：Java VM启动以来的最大活动线程数

守护线程：当前的守护线程数量。

已启动线程总数：Java VM启动后启动的线程总数，包括守护进程，非守护进程和终止线程。

Classes

当前加载的类：当前加载到内存中的类的数量。

加载的总类数：自Java VM启动以来加载到内存中的类的总数，包括随后被卸载的类。

卸载的总类数：自Java VM启动以来从内存中卸载的类的数量。

Memory

当前堆大小：堆当前占用的千字节数。

提交内存：分配给堆使用的内存总量。

最大堆大小：堆占用的最大千字节数。

终止对象：终止对象的数量。

垃圾收集器：关于垃圾收集的信息，包括垃圾收集器名称，执行的收集数量以及执行GC所花费的总时间。

Operating System

总物理内存：操做系统具备的随机存取内存（RAM）的数量。

可用物理内存：可用于操做系统的可用RAM的数量。

提交的虚拟内存：保证可用于正在运行的进程的虚拟内存量。

Other Information

VM参数：应用程序传递给Java VM的输入参数，不包括主方法的参数。

类路径：系统类加载器用于搜索类文件的类路径。

库路径：加载库时要搜索的路径列表。

引导类路径：引导类加载器使用引导类路径来搜索类文件。

Monitoring and Managing MBeans

“MBeans”选项卡以通用方式显示有关在平台MBean服务器中注册的全部MBean的信息。MBeans选项卡容许您访问整套平台MXBean工具，包括在其余选项卡中不可见的工具。另外，您可使用MBeans选项卡监视和管理应用程序的MBean。

左边的树显示当前正在运行的全部MBean。当您在树中选择一个MBean，它的MBeanInfo和MBean描述都显示在右侧，和任何属性，操做或通知出如今其下方的树。

全部的平台MXBeans及其各类操做和属性均可以经过JConsole的MBeans选项卡访问。

Constructing the MBean Tree

默认状况下，MBean根据其对象名称显示在树中。JConsole在将MBean添加到MBean树时保留建立对象名称时指定的关键属性的顺序。JConsole用于构建MBean树的确切键属性列表将是ObjectName.getKeyPropertyListString（）方法返回的类型，第一个键为type，第二个键为j2eeType（若是存在）。

可是，当JConsole呈现MBean树时，依赖于ObjectName关键属性的默认顺序有时会致使意外的行为。例如，若是两个对象名称具备类似的键，但键顺序不一样，则相应的MBean将不会在MBean树中的同一节点下建立。

例如，假设您使用如下名称建立Triangle 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的子节点。另外两个等腰三角形name = 1和name = 3将被组合在称为isosceles的不一样节点的Triangle下，如图3-13所示