简介: 责怪糟糕的代码(或不良代码对象)并不能帮助您发现瓶颈,提高 Java™ 应用程序速度,猜测也不能帮您解决。Ted Neward 引导您关注 Java 性能监控工具,从 5 个技巧开始,使用 Java 5 的内置分析器 JConsole 收集和分析性能数据。
当应用程序性能受到损害时,大多数开发人员都惊慌失措,这在情理之中。跟踪 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
当应用程序性能受到损害时,大多数开发人员都惊慌失措,这在情理之中。跟踪 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