作者将深度挖掘Java平台的核心功能。揭示一些鲜为人知的事实。帮助您解决最棘手的编程困难。
当应用程序性能受到损害时，大多数开发者都惊慌失措。这在情理之中。
跟踪Java应用程序瓶颈来源一直以来都是非常麻烦的，由于Java虚拟机有黑盒效应，并且Java平台分析工具一贯就有缺陷。
然而，随着Java5中JConsole的引入，一切都发生了改变。
JConsole是一个内置Java性能分析器，能够从命令行或在GUIshell中执行。它不是完美的，可是当尖头老板来问你关于性能的问题时，用它来应对还是绰绰有余的--这比查询PapaGoogle要好得多。
我们将向您展示5个方法，使您能够轻松地使用JConsole(或者，它更高端的"近亲"VisualVM)来监控Java应用程序性能和跟踪Java中的代码。
1.JDK附带分析器
很多开发者没有意识到从Java 5開始JDK中包括了一个分析器。
JConsole(或者Java平台最新版本号。VisualVM)是一个内置分析器，它同Java编译器一样easy启动。
假设是从命令行启动，使JDK在PATH上，执行jconsole就可以。
假设从GUIshell启动，找到安装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清理流出现，否则不会出现。这就是分析器的性能开销。
JConsole或VisualVM?
JConsole从Java 5開始就随着Java平台版本号一起公布，而VisualVM是在NetBeans基础上升级的一个分析器，在Java 6的更新版12中第一次公布。多数技巧和这两个分析器都有关,在这里主要分析JConsole
2.远程连接进程
由于Web应用程序分析工具如果通过一个套接字进行连通性分析，您仅仅须要进行少许配置来设置JConsole(或者是基于JVMTI的分析器。就这点而言)，监控/分析远程执行的应用程序。
假设Tomcat执行在一个名为"webserve"的机器上，且JVM已经启动了JMX并监听port9004,从JConsole(或者不论什么JMXclient)连接它须要一个JMX URL"service:jmx:rmi:///jndi/rmi://webserver:9004/jmxrmi".
基本上，要分析一个执行在远程数据中心的应用程序server，您所须要的不过一个JMX URL.
3.跟踪统计
JConsole有很多对收集统计数据实用的选项卡，包含：
◆Memory:在JVM垃圾收集器中针对各个堆跟踪活动。
◆Threads:在目标JVM中检查当前线程活动。
◆Classes:观察VM已载入类的总数。
这些选项卡(和相关的图表)都是由每一个Java 5及更高版本号VM在JMXserver上注冊的JMX对象提供的。是内置到JVM的。一个给定JVM中可用bean的完整清单在MBeans选项卡上列出，包含一些元数据和一个有限的用户界面来查看数据或运行操作。(然而，注冊通知是在JConsole用户界面之外。)
使用统计数据
假设一个Tomcat进程死于OutOfMemoryError.假设您想要弄清楚发生了什么，打开JConsole,单击Classes选项卡。过一段时间查看一次类计数。假设数量稳定上升，您能够假设应用程序server或者您的代码某个地方有一个ClassLoader漏洞，不久之后将耗尽PermGen空间。假设须要更进一步的确认问题。请看Memory选项卡。
不要成为典型
发现应用程序代码中性能问题的经常使用响应多种多样，但也是可预測的。早期的Java编程人员对旧的IDE可能十分生气。并開始进行代码库中主要部分的代码复查，在源码中寻找熟悉的"红色标志",像异步块、对象配额等等。
随着编程经验的添加，开发者可能会细致研究JVM支持的-X标志。寻找优化垃圾收集器的方法。
当然，对于新手，直接去Google查询，希望有其它人发现了JVM的奇妙的"make it go fast"转换，避免重写代码。
从本质上来说，这些方法没什么错，但都是有风险的。对于一个性能问题最有效的响应就是使用一个分析器--如今它们内置在Java平台，我们确实没有理由不这样做!
4.为离线分析创建一个堆转储
生产环境中一切都在高速地进行着，您可能没有时间花费在您的应用程序分析器上，相反地。您能够为Java环境中的每一个事件照一个快照保存下来过后再看。在JConsole中您也能够这样做，在VisualVM中甚至会做得更好。
先找到MBeans选项卡，在当中打开com.sun.management节点，接着是HotSpotDiagnostic节点。如今。选择Operations,注意右边面板中的"dumpHeap"button。
假设您在第一个("字符串")输入框中向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中隐藏着一整套工具。仅仅是大多数开发者并不知道。