关于 Java 性能监控您不知道的 5 件事，第 1 部分

当应用程序性能受到损害时，大多数开发人员都惊慌失措，这在情理之中。跟踪 Java 应用程序瓶颈来源一直以来都是很麻烦的，因为 Java 虚拟机有黑盒效应，而且 Java 平台分析工具一贯就有缺陷。

然而，随着 Java 5 中 JConsole 的引入，一切都发生了改变。JConsole 是一个内置 Java 性能分析器，可以从命令行或在 GUI shell 中运行。它不是完美的，但是当尖头老板来问你关于性能的问题时，用它来应对还是绰绰有余的 — 这比查询 Papa Google 要好得多。

在本期 5 件事 系列中，我将向您展示 5 个方法，使您可以轻松地使用 JConsole（或者，它更高端的 “近亲” VisualVM ）来监控 Java 应用程序性能和跟踪 Java 中的代码。

1. JDK 附带分析器

许多开发人员没有意识到从 Java 5 开始 JDK 中包含了一个分析器。JConsole（或者 Java 平台最新版本，VisualVM）是一个内置分析器，它同 Java 编译器一样容易启动。如果是从命令行启动，使 JDK 在 PATH 上，运行 jconsole 即可。如果从 GUI shell 启动，找到 JDK 安装路径，打开 bin 文件夹，双击 jconsole 。

当分析工具弹出时（取决于正在运行的 Java 版本以及正在运行的 Java 程序数量），可能会出现一个对话框，要求输入一个进程的 URL 来连接，也可能列出许多不同的本地 Java 进程（有时包含 JConsole 进程本身）来连接。

JConsole 或 VisualVM?

JConsole 从 Java 5 开始就随着 Java 平台版本一起发布，而 VisualVM 是在 NetBeans 基础上升级的一个分析器，在 Java 6 的更新版 12 中第一次发布。多数商店还没有更新到 Java 6 ，因此这篇文章主要介绍 JConsole 。然而，多数技巧和这两个分析器都有关。（注意 ：除了包含在 Java 6 中之外，VisualVM 还有一个独立版下载。下载 VisualVM，参见 参考资料 。）

使用 JConsole 进行工作

在 Java 5 中，Java 进程并不是被设置为默认分析的，而是通过一个命令行参数 — -Dcom.sun.management.jmxremote — 在启动时告诉 Java 5 VM 打开连接，以便分析器可以找到它们；当进程被 JConsole 捡起时，您只能双击它开始分析。

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

 

2. 远程连接进程

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

如果 Tomcat 运行在一个名为 “webserve” 的机器上，且 JVM 已经启动了 JMX 并监听端口 9004，从 JConsole（或者任何 JMX 客户端）连接它需要一个 JMX URL “service:jmx:rmi:///jndi/rmi://webserver:9004/jmxrmi”。

基本上，要分析一个运行在远程数据中心的应用程序服务器，您所需要的仅仅是一个 JMX URL。更多关于使用 JMX 和 JConsole 远程监控和管理的信息，参见 参考资料 。）

 

3. 跟踪统计

不要成为典型

发现应用程序代码中性能问题的常用响应多种多样，但也是可预测的。早期的 Java 编程人员对旧的 IDE 可能十分生气，并开始进行代码库中主要部分的代码复查，在源代码中寻找熟悉的 “红色标志”，像异步块、对象配额等等。随着编程经验的增加，开发人员可能会仔细研究 JVM 支持的 -X 标志，寻找优化垃圾收集器的方法。当然，对于新手，直接去 Google 查询，希望有其他人发现了 JVM 的神奇的 “make it go fast” 转换，避免重写代码。

从本质上来说，这些方法没什么错，但都是有风险的。对于一个性能问题最有效的响应就是使用一个分析器 — 现在它们内置在 Java 平台 ，我们确实没有理由不这样做！

JConsole 有许多对收集统计数据有用的选项卡，包括：

• Memory ：在 JVM 垃圾收集器中针对各个堆跟踪活动。
• Threads ：在目标 JVM 中检查当前线程活动。
• Classes ：观察 VM 已加载类的总数。

这些选项卡（和相关的图表）都是由每个 Java 5 及更高版本 VM 在 JMX 服务器上注册的 JMX 对象提供的，是内置到 JVM 的。一个给定 JVM 中可用 bean 的完整清单在 MBeans 选项卡上列出，包括一些元数据和一个有限的用户界面来查看数据或执行操作。（然而，注册通知是在 JConsole 用户界面之外。）

使用统计数据

假设一个 Tomcat 进程死于 OutOfMemoryError 。如果您想要弄清楚发生了什么，打开 JConsole，单击 Classes 选项卡，过一段时间查看一次类计数。如果数量稳定上升，您可以假设应用程序服务器或者您的代码某个地方有一个 ClassLoader 漏洞，不久之后将耗尽 PermGen 空间。如果需要更进一步的确认问题，请看 Memory 选项卡。

 

4. 为离线分析创建一个堆转储

生产环境中一切都在快速地进行着，您可能没有时间花费在您的应用程序分析器上，相反地，您可以为 Java 环境中的每个事件照一个快照保存下来过后再看。在 JConsole 中您也可以这样做，在 VisualVM 中甚至会做得更好。

先找到 MBeans 选项卡，在其中打开 com.sun.management 节点，接着是 HotSpotDiagnostic 节点。现在，选择 Operations ，注意右边面板中的 “dumpHeap” 按钮。如果您在第一个（“字符串”）输入框中向 dumpHeap 传递一个文件名来转储，它将为整个 JVM 堆照一个快照，并将其转储到那个文件。

稍后，您可以使用各种不同的商业分析器来分析文件，或者使用 VisualVM 分析快照。（记住，VisualVM 是在 Java 6 中可用的，且是单独下载的。）

 

5. JConsole 并不是高深莫测的

作为一个分析器实用工具，JConsole 是极好的，但是还有更好的工具。一些分析插件附带分析器或者灵巧的用户界面，默认情况下比 JConsole 跟踪更多的数据。

JConsole 真正吸引人的是整个程序是用 “普通旧式 Java ” 编写的，这意味着任何 Java 开发人员都可以编写这样一个实用工具。事实上，JDK 其中甚至包括如何通过创建一个插件来定制 JConsole 的示例（参见 参考资料 ）。建立在 NetBeans 顶部的 VisualVM 进一步延伸了插件概念。

如果 JConsole（或者 VisualVM，或者其他任何工具）不符合您的需求，或者不能跟踪您想要跟踪的，或者不能按照您的方式跟踪，您可以编写属于自己的工具。如果您觉得 Java 代码很麻烦，Groovy 或 JRuby 或很多其他 JVM 语言都可以帮助您更快完成。

您真正需要的是一个快速而粗糙（quick-and-dirty）的由 JVM 连接的命令行工具，可以以您想要的方式确切地跟踪您感兴趣的数据。

 

结束语

Java 性能监控不止于 JConsole 或 VisualVM — 在 JDK 中隐藏着一整套工具，只是大多数开发人员并不知道。 本系列 中的下一篇文章将深入探究一些实验性的命令行工具，可以帮助您挖掘更多的您所需要的性能数据。因为这些工具通常只关注特殊数据，比一个完整的分析器更小更轻巧，所以它们的性能开销要小一些。

 

 

原文：http://www.ibm.com/developerworks/cn/java/j-5things7.html