JRockit JVM整合了JRockit Deterministic Garbage Collector技术，能够在垃圾收集中最糟糕的情况下保证一个暂停时间的上限。这非常有助于减少意外的延迟。然而，编写Java应用程序时，依然有可能因未通过最优化的方式使用Java同步、I/O等方面而造成延迟。这些延迟可能会导致应用程序性能低下和/或响应时间过长，而且难以发现原因所在。延迟分析器提供了一种简单的方法，可以分析此类延迟的缘由。
JRockit Latency Analyser通过Mission Control 3.0构建于JRA（JRockit Runtime Analyzer）之中。现在，启动JAR记录时，就可以选择一个Latency Recording Profile。
选择此类配置文件时，或者从高级选项中选择了Enable Latency Recording时，记录的配置文件将包含延迟信息。记录包含此类信息时，将出现三个额外的选项卡（Latency Log、Latency Graph、Latency Traces）、两个视图（Event Types、Properties）和一个新的Latency Perspective供您使用。
Latency Log选项卡包含一份日志记录，其中以表的形式列出所有事件，并允许您填充。
Latency Graph选项卡包含一个图表，为各线程显示记录期间已发生的延迟事件。
Latency Traces选项卡包含一份树形表视图，为您显示了参与导致这些延迟的堆栈跟踪（stacktrace）；以及这些跟踪给一个特定节点造成了多少延迟。
在下面的示例中，我们发现那些对延迟敏感的应用程序的响应时间有些令人失望。CPU未饱和，所以我们决定使用一个包含延迟信息的JRA记录。现在我们在延迟图表中（下图）查看该记录。在各视图的顶端是范围选择工具，可进行缩放（zoom and pan）来过滤较旧的事件。此图中已缩小范围。这个特殊的记录展示出，在整个记录中存在的问题是完全相同的，因而查看另外一部分将得到极为类似的图形。
从该图表中可以看出，我们似乎进行了大量Java同步。在日志视图中（即下图所示屏幕快照）可以查看各独立事件。该屏幕视图中已过滤为仅显示Java Synchronization Events，还将开头的几个事件添加到Operative Set中。即Range Selector中突出显示的那几个事件。看上去大部分事件就是Java Synchronization Event。仅选择Java Synchronization Events的另外一种方法是在Event Type视图中清除对其他Event Types的选择。
如果切换到跟踪视图，那么就可以看到几乎所有的延迟都是由对一个java.util.logging Logger的调用导致的。
现在，如果删除那些日志调用，就几乎不存在什么Java Synchronization事件了，因而由这些事件导致的延迟也就不存在了。下图展示了消除日志调用后的记录。
JRockit Mission Control 3.0包含在JRockit R27.3 JDK之中，将于近日公布。要进一步了解Mission Control 3.0的特性，请参见R27.3发布说明和Mission Control文档。
关于Mission Control 2.0附带产品的更多信息，请阅读上一篇博客文章——Mission Control 2.0 Sneak Peak。
关于如何获得免费评估/开发许可的信息，请访问 Mission Control主页。
原文出处：http://dev2dev.bea.com/blog/hirt/archive/2007/07/the_mission_con.html
