当应用程序性能受到损害时，大多数开发人员都惊慌失措，这在情理之中。跟踪 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 进行工作

在 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. 跟踪统计

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

为什么问题诊断如此复杂？ 软件开发网
　　对于 WebLogic 应用程序的某个具体应用模式来说，没有既定的公式可以用来推导出它的性能(在严格的实时工程当中，速度单调分析这类技术确实可以做这项工作，但是在本文里还是让我们忘记它吧)。网络上是否存在另外一个系统正在密集使用一个共享的后端服务，对于实际产生的性能有很大影响。性能也许还取决于 JDBC 驱动程序版本和数据库的正确匹配。也许开发人员三年前写的一些代码恰巧在这个时候才出现特定类型的异常，而您急切需要的解决问题回馈，却恰恰包含在这个异常里。
　　从本质上说，典型业务系统的性能是由成千上万交互的变量和决策共同作用的结果。就像人体一样，有太多连锁着的部分和过程，所以很难理解系统的整体。因此我们进行了简化，并求助于拱形模式。

疾病
　　您看到的症状的根本原因是什么？它是初级流行性感冒或者是肺炎的开始吗？是应用程序内部的底层问题还是它所在的 JVM 外部的问题？请参阅表 1 中应用程序性能低下的一些最常见原因。

表1

测量关键的统计指标

实验工作
　　有的时候，在一次标杆运行中获得的数据，不足以揭示答案。那么找到答案的机会就在于您还有些有限的预算，可以运行试验或者做实验工作，来完成诊断。您可以运行什么类型的试验呢？您可以修改、观察什么变量呢？

http://www.mscto.com

诊断：测试您的推测
　　在这个时候，您应当已经有了足够的信息，可以形成关于性能瓶颈原因的推测了(请参阅表 1)。为了验证您的推测是否正确或者在多个备选的推测之间进行筛选，您需要分析更多的信息或者在系统上运行更多的标杆测试。这里是一些可以帮助您的指导意见：
区分糟糕的编码(或者是应用程序组件或者是桥接层)和瓶颈 (内部的或外部的)，请查看整体的 CPU 使用情况。如果它在负载下没变化，但是整体响应时间变化了，那么就是应用程序花费了它的大多数时间来等待。 仅仅是因为好像是外部资源的问题，不代表您就可以立刻把责任推到资源上。 例如，分层或联网的问题，也能造成数据库看起来很慢，虽然实际上它并不慢。或者，更简单一点，您对数据库的请求可能是不合理的(每次用户登录的时候，都要进行三个表之间的 200 万行记录合并)。应当一直把桥接层的响应时间(例如，JDBC 驱动器)和资源提供的时间或者工具提供的时间进行比较(例如，DBA Studio)。 结构化的图表有助于您理解系统内部的整体交互，但是不要忘记地图并不是领地。.编码错误或者对架构意图的误解，有可能使系统的实际行为与期望的行为不同。请相信性能工作提供的实际数据，而不要相信一个声称“每个用户事务将只会发布一个 SQL 语句”这样的文档。 使用 Occam 军刀。 假设您有两个备选推测，一个是：在 200 万行代码里，有一个编码糟糕的组件，直到上周这个组件才集成进来；另一个是 JVM 的即时编译器生成了糟糕的机器码，破坏了这个变量的内存完整性。除非您有具体的数据来证实，否则(我已经看到了第二种情况发生)，请更详细地检查第一个假设。J2EE 系统确实容易出错，但是不要让这一点就妨碍您先测试一个更简单的假设。 日志文件中没有错误不代表不存在错误。 有许多原因可以造成不在日志里写下异常；可能是因为程序员认为某件事“永远不会发生”，于是就排除了这个异常；也可能是因为某些组件可以使用故障恢复机制，所以就没有记录第一次故障。

示例诊断
　　让我们来实际研究一个示例。您的 WebLogic 应用程序表现出在负载下越来越慢的症状。您加入的用户越多，系统越慢。一旦消除负载，系统就冷静下来，没有任何后遗症。您对这一主要症状进行测试，发现并得到图 2 所示的以下结果(时间测量针对的是单一典型事务的端到端完成时间)。

表2

负载(用户数) 来回用时(毫秒) 10 300 50 471 100 892 150 1067

应用程序性能在负载下越来越慢

http://www.mscto.com

　　您形成了几个假设。也许这里的毛病是一个糟糕编码的组件，也许是后端系统的瓶颈。它可能是一个同步阻塞点。您怎样才能分清它们的不同呢？假设您还测试了应用程序服务器在负载运行期间的CPU整体使用情况，并得到了表 3 所示的结果。

表3

负载(用户数) 来回用时(毫秒) 整体 CPU 时间(%) 10 300 30 50 471 33 100 892 37 150 1067 41

问题看起来好像是“等待”瓶颈

　　现在看起来，系统不是 CPU 密集型的，这就是说它的多数时间都花在等待上了。那么是它的内部(例如，同步交通阻塞)或外部(缓慢的数据库)的问题？好，让我们假设我们还稍微多搜集了一些数据，如表 4 所示。

表4

负载(用户数) 等待数据库连接的线程数量 JDBC 查询用时(毫秒) 10 2 58 50 3 115 100 3 489 150 4 612

问题是否出在一个缓慢的 SQL 语句上呢？

表5

　　如果您没有看到这条信息，那么您可能要返回 JDBC 驱动程序，期待能够发现其中的某些同步问题(请记住，CPU 没有被抑制)。幸运的是，在这个案例里，您已经把具体问题的范围缩小到数据库查询上。找出查询请求是否足够合理，需要一些相关领域的知识，需要熟悉系统，但是在这个案例里，它也许就是发现查询把非索引字段和外键进行了比较。您和 DBA 协作，它修改索引方案，让查询变得更快，而您则找到了您的药方。

结束语
　　诊断 WebLogic J2EE 应用程序的性能瓶颈是一个艰苦的旅程。请随时保持清醒，把事实与推测分开，总是用实际的证据来确认您的推测。我希望给您带来了思考和实践问题的一些有用的想法的分类。就像调试，这仍然是一项不明确的艺术，但是深思熟虑会带您走出困境。祝您好运!

关于作者
　　John Bley 是 Wily Technology 的软件工程师。他有丰富的 Java 编程和架构经验。为了撰写本文，他总结了 Wily 的企业客户的经验，Wily负责管理复杂的 J2EE 环境。(更多)
原文出处 http://www.sys-con.com/story/?storyid=43024&DE=1

一、Page Speed的安装及使用

Page Speed是一款Firefox插件，同时他依附于别款插件Firebug，也就是说你的Firefox浏览器中必须已经安装了Firebug才能安装Page Speed。安装环境为Firefox 3.0.4以上，Fireug 1.3.3以上。

Page Speed的使用也很简单，在Firefox中点击右下角的Firebug图标启动后，再点击Page Speed选项卡即可。要注意的是，你要对你网站内的某个页面进行性能分析，你必须先把该页面加载完成后才能使用Page Speed，也就是说只有在浏览器左下角出现“Done”或者"完成"之后才可以启用Page Speed进行分析。如果页面中流媒体，可能不会现在“完成”，这种情况要等到流媒体可以播放。

 

然后点击“Analyze Performance”（性能分析），这时Page Speed会根据web performance best practices （网页性能最佳实践）进行逐项打分。然后根据重要程序和优先级对每项进行排列。

此外，你还可以点击每条建议前面的“加号”展开查看详细的描述，或者直接点击每条规则相看该规则的具体内容，还可以点击“Show Resource”（查看来源）来查看每条建议是针对页面中哪部分内容提出的。

对于分析结果中的符号说明一下：

1. 红色感叹号代表高优先级提示，表示这一项严重影响了你的页面性能，你需要优先对其进行性能优化；
2. 橙色三角代表此项提示需要引起你的注意，并进行适当改进；
3. 绿色的对号代表该项规则在你的网站中应用得到，你在修改了前面两部分的提示之后，它们有可能变为绿色的对号；
4. 蓝色消息符号是为你提供了额外的帮助信息，请稍加留意（需要注意的是，如果你的页面中出现了大量的此类符号，可能是因为你在页面加载完成之前就进行了网站性能分析）。

二、活动记录

活动记录是一条页面活动的时间轴，它记录了包括网络事件、JavaScript运行在内的所有浏览器活动。你可以使用它并配合性能分析中的数据进一步对网站性能做出评估。

• 查看页面运行过程中所耗费的时间，以毫秒计算；
• 查看浏览器事件，包括页面加载完成后的事件；
• 区分造成页面响应缓慢的原因，其中包括网络来时、DNS查找、连接建立、JavaScript运行等；
• 获取在特定时间或者事件下才响应的JavaScript事件列表；
• 可以对其它标签或者窗口中打开的页面进行分析；
• 多页面加载时的页面加载顺序；
• 对根据Page Speed优化前后的表现进行对比。

三、理解Page Speed中的事件

页面记录选项卡下是通过时间线来记录各种资源加载到页面所有需要的时间。事件的记录时间间隔为10毫秒，如果事件需要的时间少于10毫秒那么它将用较短的色块来表示。时间线中没有任何颜色的表示，在浏览器事件的运行依赖于其它进程，如DOM和CSS渲染、Flash ActionScript、渲染、操作系统事件等。

此外，Page Speed还包括了对已完成的JavaScript函数的信息搜集功能，当页面中的JS函数一旦运行，PageSpeed就会捕捉到相关信息。不通过对Page Speed进行设置还可以对未触发函数、延时加载函数等进行收集。

下面的图片显示了7800毫秒时已经加载但还未触发的函数列表：

而下面则显示是已经触发运行了的JS函数：

此外Pge Speed还有诸如JavaScript函数控制、浏览器User Agent设置等更高级功能。具体使用大家可以与YSlow对比一下。

相信，用好这两款工具，对于站长和网站开发者来说会有极大的帮助。

本文网址： http://www.dudo.org/article/NewSoftware/using_google_page_speed.htm
转载请注意出处