Quest JProbe最佳实践指南(上)
一 介绍
在Java的广泛应用中，一个关键驱动因素是由于使用标准类库和应用框架从而提高了生产效率。通过减少必要的设计，实现和调试等软件开发任务，Java在各种平台之间极大地改善了集成性和互操作性；其它的开发环境都不能提供象Java那样的强大功能。实际上，没有一个环境象J2EE那样具有明显的基于框架开发的优点，J2EE能够快速地构建可扩展，分布式的安全企业级应用。
虽然这些优点一直在促进J2EE的空前发展，但也经常出现一些麻烦，那就是人们经常对J2EE应用的性能感到失望。因此，我们需要一些工具和调查策略来帮助J2EE开发团队解决这些性能问题。这就是Quest JProbe Profiler和Jprobe Memory Debugger所要解决的问题。
1.1 J2EE性能概揽
一般情况下，最终用户对J2EE应用性能的体验与下面层次是紧密相关的:
1 J2EE体系结构图
- J2EE应用是指servlets，JSPs，EJBs和支持类，它们在J2EE应用服务器的上下文环境中构成了客户的应用。
- J2EE应用服务器是指J2EE应用服务器基础结构的设计，实现和配置，它们提供了客户J2EE应用的上下文环境。
- JAVA运行环境是指JAVA虚拟机及其配置(堆的大小等等)的设计和实现。
- 平台-底层硬件(如CPU的数目，内存的大小，I/O子系统等)和操作系统设计，实现和配置(线程和进程调度，子系统优化，整体负载等) 。
虽然毫无疑问，底部层次会影响整个性能，经验也不断地表明，性能下降的普遍原因是由组成J2EE应用的Servlets，JSPs和EJBs的设计问题和不佳的实现造成的。本文将集中讨论在这个底层中如何识别出性能下降的原因
1.2 概述
本文描述了在BEA WebLogic Server6.1上下文环境中，怎样用Quest JProbe Memory Debugger和Profiler分析J2EE应用。包括三个主要部分:
- 设置-在介绍JProbe的体系结构之后，我们将描述怎样把JProbe Memory Debugger和Profiler集成到WebLogic Server6.1环境中。
- 对象循环分析-在J2EE应用中，性能下降的普遍原因是创建过多的短期对象(也可称为对象循环)。在这部分里，我们将展示怎样使用JProbe Memory Debugger's Garbage Monitor识别大量创建短期对象的方法。这些是进一步分析减少创建过多对象的最佳方法。
- J2EE性能分析-最后，我们将使用JProbe Profiler向你介绍怎样进行J2EE应用的性能分析，并且在语句级上快速地识别出一些耗时最多的方法。
2. 集成BEA weblogic 服务器和Quest JProbe
2.1 Quest JProbe
Quest JProbe产品线由一族工具组成，该族工具包括下面四个分析工具。
- JProbe Memory Debugger-检查Java软件的内存使用情况。
- JProbe Profiler-剖析Java软件的性能。
- JProbe Threadalyzer-识别线程级的死锁和错误的访问冲突
- JProbe Coverage-通过提供的语句级执行信息验证测试框架的完整性。
虽然本文集中讨论了JProbe Memory Debugger和Profiler，但所有四个工具都采用了相同的体系结构设计，并且与BEA WebLogic服务器的集成方法是相同的。
2.1.1 JProbe的体系结构
一个基于JProbe的调查会话由两个程序组成:
图2 JProbe体系结构JProbe控制台是一个基于Swing的Java应用，它提供了用户图形界面（GUI），用于建立调查会话，在程序运行时查看分析信息和深入分析Snapshot文件中的信息内容。
测试型Java虚拟机-JProbe通过JVMPI(Java Virtual Machine Profiling Interface)提供的回调方法，使用标准的Java虚拟机运行Java应用并收集分析信息，该虚拟机是由厂商提供的。在剖析基于WLS的J2EE应用中，Java应用运行在Java虚拟机中，该虚拟机由WebLogic服务器的基本框架组成，就象J2EE应用部署到上面一样。
这种结构具有非常灵活的启动方式。你可以从用户图形界面本身启动测试型Java虚拟机，也可以单独启动测试型Java虚拟机并且使它连接上JProbe控制台。
2.2 使用JProbe Application Server Integration Tool
1. 启动JProbe Application Server Integration。
2. 从左上角下拉列表中选择你要集成的BEA Weblogic服务器版本。
3. 点击"Create"按钮。编辑窗口右边的内容，如图3所示。
4. 编辑下面区域或使用默认值。
Integration ID: JProbe Demo 1 Integration ID ，便于重用每次集成过程 Server Directory: D:\bea\wlserver6.1 直接输入 WLS 服务器根路径或者通过 " 浏览 " 方式输入。 Domain Name: Mydomain 输入你想分析的域名。 Startup Script: StartWeblogic.cmd 直接输入要调查的服务器的启动脚本或者通过 " 浏览 " 方式输入。 JProbe Settings: (JPL File) check the VAR checkbox 集成工具允许你使用先前创建的 JPL(JProbe Launchpad) 文件。 如果要使用由每个工具在启动时默认创建的 JPL 文件，选择 VAR 复选框。 Java Executable: d:\sun\jdk1.3.1\bin\Java.exe 可直接输入或通过浏览方式输入 Java 虚拟机的执行文件路径。 5. 点击"Advanced>>"按钮。
6. 填写下面这区域。
Java Options: -classic -mx128m -ms64m 有选择地给 Java 虚拟机输入参数。 7. 点击"Save"按钮。
图 4 ． JProbe Application Server Intergation 窗口
你已经成功创建和BEA Weblogic6.1的集成， 所有四个工具都可以使用这个集成过程。
8. 点击"Close"按钮。
3. 识别J2EE应用性能下降
JProbe Memory Debugger能帮助你追踪到游离对象（loitering objects）和减少创建过多的对象，并且JProbe Profiler能帮助你发现性能瓶颈。根据具体情况，需要具体分析。在这里，我们简单地概括用于解决对象循环和性能瓶颈这两个常见问题的步骤。更多的信息和其它使用JProbe Memory Debugger和Jprobe Profiler的方法，可以参考在线帮助或者阅读JProbe Memory Debugger Guide和JProbe Profiler Developer's Guide。
3.1 对象循环（Object Cycling）
Java应用性能下降的一个主要原因是创建过多的对象 (或称为对象循环)。Java虚拟机分配了过多的内存，创建了不必要的对象并对这些对象的初始化，加大了垃圾回收活动，从而引起性能下降。
作为一个性能分析人员，你首先需要识别出创建大量短期对象的方法。这些方法是进一步做减少创建对象数量分析的理想入手点。。JProbe Memory Debugger提供的一个垃圾监视功能可以把对象和分配它们的方法连接起来，并且当你的应用运行时，可以追踪有多少对象已经被垃圾回收了。
3.1.1 启动JProbe Memory Debugger的研究会话
1. 启动JProbe Memory Debugger。当欢迎界面出现的时候，点击"Run"开始启动。
图 5 ． JProbe 欢迎界面
2. 在JProbe LaunchPad窗口中:
a． 选择"Using Application Server"
b． 从"Application Server"下拉的菜单中选择BEA Weblogic6.1
c． 注意在"Integration ID"下拉的菜单中填写JProbe Demo 1
3. 选择"Filter"
a． 点击"Please enter a package，or method to display data for"。输入你要调查的包:profiler.com.quoteme.stockwatch
b． 在"Display"栏的下拉菜单里选择"Display"
4. 选中"Monitor Garbage Collections from Program Start"复选框。
5. 选择"Snapshot Directory:"为d:\temp。
6. 点击"Run"按钮。
图7．JProbe LaunchPad Pad窗口
当WebLogic Server初始化时，Runtime Heap Graph将增高，这反映了对象创建和垃圾回收活动。一旦WebLogic Server已经被充分初始化后，你就可以开始着手分析了。
3.1.2 运行时交互
一旦WebLogic Server已经充分初始化，选择你想要用于分析对象循环的应用用例。选择Grabage Monitor标签，按下面的步骤:
1. 首先运行一次Garbage Collection ，回收在Java堆中分配的，但不再使用的对象。Garbage Monitor表随时更新反映这些被回收对象的情况。
2. 点击"Clear Table"清空Garbage Monitor表。
3. 运行你的应用用例。当Java虚拟机开始垃圾回收时，Grabage Monitor表将随之更新。
提示:在Heap Usage Chart中寻找负载峰值。急剧升降的负载峰值意味着一些对象在被垃圾回收之前只存活了很短的时间。连在一起的一些急剧升降的负载峰值是一个明确的信号，意味着是一个对象循环问题。
4. 在完成你应用用例后，再次运行Garbage Collection ，回收最后分配但不再使用的对象。
3.1.3 分析结果
当会话结束时，Garbage Monitor中包含了已回收最多实例的前十个类。通常，这些类不是你自己应用的类，准确地说，它们是被你的一些方法(直接地或间接地)分配的第三方的类。最后一列是分配这些已回收对象的方法名。
提示:如果被不同方法分配的实例属于同一个类，并且都是前十个类的话，你将见到两行相同的类。
1. 使用Filter Allocating Methods，只显示你包中的一些方法，屏蔽掉其它包中的方法。在我们的例子中，客户J2EE应用定义在profiler.com.quoteme.stockwatch包里面，所以我们把过滤规范profiler.com.quoteme.stockwatch.*.*输入到Filter Allocating Methods文本输入控制中。
2. 在GC'ed列中，你能看到你的方法分配了多少实例。作为比较，查看Alive列就能看到还有多少实例仍在堆中。Java开发者通常会对创建和移走了多少对象而感到惊奇。
3. 现在你已经识别到你有问题的方法。想想你可能怎样修改这些分配对象的方法，从而减少或排除对象循环？例如，你可以尝试重用某个对象或者创建一个可重用的对象池。
4. WebLogic Server6.1编译JSP后，自动产生了一个servlet类名，并赋予一个包名和类名。例如，如果有一个名为TestJSP.jsp的JSP文件，将被编译成名为jsp_servlet.__testjsp的类(JSP名跟着两个下划线，并且都是小写字母)。
用Filtering Classes为jsp_servlet.*限制Garbage Monitor中的内容，可以看到已经被垃圾回收到Garbage Monitor中的JSP。在Filtering Allocating Methods设置jsp_servlet.*.*或jsp_servlet._<你的JSP名>.* 限制Garbage Monitor中的内容，可以从分配的角度在指定的JSP中查看垃圾回收对象。
更深入的研究
如果你分配的方法没有一个出现在Garbage Monitor中，或者在修改明显的问题后，仍然有对象循环的问题；你需要进行堆栈跟踪，检查哪个方法的调用导致了创建实例并分配了空间。需要使用heap snapshot查看堆栈跟踪。要了解更多的信息，请看在线帮助里的Garbage Collection Tutorial或者JProbe Memory Debugger Developer's Guide。
电子邮件订阅：本网站提供数据库管理软件最新下载，数据库相关软件最新产品动态，数据库软件使用经验，数据库相关软件最佳实践，如果您对我们的网站内容感兴趣,可进行电子邮件订阅.注册/登录后进入"管理我的订阅">>"我的订阅",选择订阅的分类即可.