QuestJProbe最佳实践指南.docx

《QuestJProbe最佳实践指南.docx》由会员分享，可在线阅读，更多相关《QuestJProbe最佳实践指南.docx（17页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Java 和J2EE 业务应用程序中的性能格外重要。当数以千计的用户使用您的应用程序时，您不能担当无视影响应用程序牢靠性和伸缩性的问题所带来的风险，和担当性能瓶颈、内存泄漏、进程以及未测试代码等问题。您也不能担当在系统体系构造上再连续花费。造成应用程序中代码错误通常由于代码虽然是源代码， 然而很多开发组在开发高性能过程中不能执行最正确的操作。因此您必需治理性能，治理风险。JProbe Suite 5.0 是 Java 最正确的性能协调组件包，供给了高级的、高敏捷性的Java 应用程序协调，而不管其在本地运行还是在远程运行。组件包中包括：JProbe Profiler、JProbe Memory

2、 Debugger、 JProbe Threadalyzer 和 JProbe Coverage。JProbe ProfilerJProbe Profiler 是一个前沿的Java 工具。JProbe Profiler 帮助开发者快速的诊断Java 代码中性能瓶颈。伴随着高准确度的诊断，以及一行行的输出结果，开发者将大大改善应用程序性能。随着客户 Java 应用程序和J2EE 应用程序的大小和简单性的增长，对快速分析力量的工具的需求也渐渐增加。JProbe Profiler 5.0 动态的改善了分析时间，能使用户的处理速度提高 10 倍。主要特性方法和行级分析-定位快速方法，逐步测量每行性能。

3、测量占用或 CPU 时间跟踪最终用户感觉的性能或计算瓶颈共性能矩阵识别性能问题的实际来源高级过滤和触发器零化代码临界区 快照差分识别代码变化对性能的影响高级打印和输出用 Acrobat PDF 打印性能分析；将列表数据发送到文本，HTML 或类似于 Excel 的 CSV格式JProbe Memory DebuggerJProbe Memory Debugger 帮助开发者快速觉察Java 代码中的内存泄漏，降低应用程序中内存的使用。Java 开发人员能承受JProbe 易于使用的查看器，导航和分行结果，可视化在内存使用和空闲对象中的简单数据。供给了以下优点：消退了花费较大的内存循环、动态提高

4、内存消耗和应用程序性能、指出产生闲散对象的缘由、承受强大的触发器零化重要代码以及良好的协调的数据集合并附带高级 API。我们为 JProbe Memory Debugger 5.0 添加了更多特性，全部这些特性都是为了削减您查找内存泄漏的时间。主要特性识别内存泄漏承受易用的 2 按钮分析和对象阀值来跟踪运行时的内存增加内存实例计算器计算内存泄漏多少智能内存分析承受 Leak Docotor 准确定位内存泄漏的可能来源引用图和实例具体信息跟踪内存使用和对象引用基于树的实例具体视图通过对象引用快速跟踪内存泄漏 垃圾收集分析监测寿命周期短的对象和垃圾收集具体信息快照差分识别代码变化对内存使用的影响J

5、Probe Threadalyzer线程为您的应用程序供给同时处理多项任务的功能。主要用于建立高性能，可缩放的应用程序,同时在效劳器端 Java 开发中占有格外重要的地位。多线程应用程序具有不加任何警告而停顿业务应用程序的缺陷。JProbe Threadalyzer 能够监测影响应用程序性能的线程错误。强大的锁定分析器能帮助您在问题发生之前推测线程中的问题。简洁使用的可视化器显示了您分析的结果， 以至于您能快速的猎取与线程相关的问题的根本。主要特性可视化图观看线程状态的变化锁定分析器在产生问题之前，推测死锁和数据跟踪状况监测特别同步避开数据错误JProbe Coverage为了确保能准确的测试

6、 Java 运行应用程序，开发者需要知道要测试多少代码量以及在何处找到未测试的代码。JProbe Coverage 帮助您定位未测试代码，准确测量执行的代码量。最终将产生高质量，耗时短的应用程序。JProbe 5.0 动态的改善了分析时间，使用户的处理速度提高了 10 倍，特别改善了Profiling 和代码掩盖局部。除了以前版本中供给的直线和方法级报表，JProbe Coverage 5.0 特性就是能生成类级掩盖报表。主要特性掩盖扫瞄器和源代码视图快速分别未检测代码和死代码批处理模式能以批处理模式运行，便利的集成建立/测试系统报表以 XML，文本，类似于 Excel 的 CSV 和 HTM

7、L 形式输出掩盖快照数据，用以定制分析快照合并合并多个平台运行的整个掩盖数据Quest JProbe 最正确实践指南 铸锐数码-编译 发文时间：2023.10.131. 介绍在 Java 的广泛应用中，一个关键驱动因素是由于使用标准类库和应用框架从而提高了生产效率。通过削减必要的设计，实现和调试等软件开发任务，Java 在各种平台之间极大地改善了集成性和互操作性；其它的开发环境都不能供给像 Java 那样的强大功能。实际上，没有一个环境像 J2EE 那样具有明显的基于框架开发的优点，J2EE 能够快速地构建可扩展，分布式的安全企业级应用。虽然这些优点始终在促进J2EE 的空前进展，但也常常消灭

8、一些麻烦，那就是人们常常对 J2EE 应用的性能感到无望。因此，我们需要一些工具和调查策略来帮助 J2EE 开发团队解决这些性能问题。这就是 Quest JProbe Profiler 和 Jprobe Memory Debugger 所要解决的问题。1.1 J2EE 性能概揽一般状况下，最终用户对 J2EE 应用性能的体验与下面层次是严密相关的:J2EE 体系构造图 J2EE 应用是指 servlets，JSPs，EJBs 和支持类，它们在J2EE 应用效劳器的上下文环境中构成了客户的应用。 J2EE 应用效劳器是指 J2EE 应用效劳器根底构造的设计，实现和配置，它们供给了客户J2EE 应

9、用的上下文环境。 JAVA 运行环境是指 JAVA 虚拟机及其配置(堆的大小等等)的设计和实现。 平台-底层硬件(如 CPU 的数目，内存的大小，I/O 子系统等)和操作系统设计，实现和配置(线程和进程调度，子系统优化，整体负载等) 。虽然毫无疑问，底部层次会影响整共性能，阅历也不断地说明，性能下降的普遍缘由是由组 成 J2EE 应用的 Servlets，JSPs 和 EJBs 的设计问题和不佳的实现造成的。本文将集中争论在这个底层中如何识别出性能下降的缘由。1.2 概述本文描述了在 BEA WebLogic Server6.1 上下文环境中，怎样用 Quest JProbe Memory D

10、ebugger和 Profiler 分析 J2EE 应用。包括三个主要局部: 设置-在介绍 JProbe 的体系构造之后，我们将描述怎样把 JProbe Memory Debugger 和Profiler 集成到 WebLogic Server6.1 环境中。 对象循环分析-在 J2EE 应用中，性能下降的普遍缘由是创立过多的短期对象(也可称为对象循环)。在这局部里，我们将展现怎样使用 JProbe Memory Debugger”s Garbage Monitor 识别大量创立短期对象的方法。这些是进一步分析削减创立过多对象的最正确方法。 J2EE 性能分析-最终，我们将使用 JProbe

11、Profiler 向你介绍怎样进展J2EE 应用的性能分析， 并且在语句级上快速地识别出一些耗时最多的方法。2. 集成 BEA weblogic 效劳器和 Quest JProbe2.1 Quest JProbeQuest JProbe 产品线由一族工具组成，该族工具包括下面四个分析工具。 JProbe Memory Debugger-检查 Java 软件的内存使用状况。 JProbe Profiler-剖析 Java 软件的性能。 JProbe Threadalyzer-识别线程级的死锁和错误的访问冲突 JProbe Coverage-通过供给的语句级执行信息验证测试框架的完整性。虽然本文集

12、中争论了 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 I

13、nterface) 供给的回调方法，使用标准的 Java 虚拟机运行 Java 应用并收集分析信息，该虚拟机是由厂商供给的。在剖析基于 WLS 的 J2EE 应用中，Java 应用运行在 Java 虚拟机中，该虚拟机由 WebLogic 效劳器的根本框架组成，就象 J2EE 应用部署到上面一样。这种构造具有格外敏捷的启动方式。你可以从用户图形界面本身启动测试型 Java 虚拟机，也可以单独启动测试型 Java 虚拟机并且使它连接上 JProbe 掌握台。2.2 使用 JProbe Application Server Integration Tool1. 启动 JProbe Applicati

14、on Server Integration。2. 从左上角下拉列表中选择你要集成的 BEA Weblogic 效劳器版本。图 3 JProbe Application Server Integration 窗口3. 点击“Create“按钮。编辑窗口右边的内容，如图 3 所示。4. 编辑下面区域或使用默认值。Integration ID:JProbe Demo 1Integration ID，便于重用每次集成过程Server Directory:D:beawlserver6.1直接输入 WLS 效劳器根路径或者通过“扫瞄“方式输入。Domain Name:MydomainStartup Scr

15、ipt:StartWeblogic dJProbe输入你想分析的域名。直接输入要调查的效劳器的启动脚本或者通过“扫瞄“方式输入。集 成 工 具 允 许 你 使 用 先 前 创 建 的Settings:(JPL File)Java Executable:check the VAR checkboxd:sunjdk1.3.1binJava.exeJPL(JProbe Launchpad)文件。假设要使用由每个工具在启动时默认创立的 JPL 文件， 选择 VAR 复选框。可直接输入或通过扫瞄方式输入 Java 虚拟机的执行文件路径。5. 点击“Advanced“按钮。6. 填写下面这区域。Java

16、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 能帮助你觉察性能瓶颈。依据具体状况，需要具体分析。在这里，

17、我们简洁地概括用于解决对象循环和性能瓶颈这两个常见问题的步骤。更多的信息和其它使用JProbe Memory Debugger 和 Jprobe Profiler 的方法，可以参考在线帮助或者阅读 JProbe Memory Debugger Guide 和 JProbe Profiler Developer”s Guide。3.1 对象循环Object CyclingJava 应用性能下降的一个主要缘由是创立过多的对象 (或称为对象循环)。Java 虚拟机安排了过多的内存，创立了不必要的对象并对这些对象的初始化，加大了垃圾回收活动，从而引起 性能下降。作为一共性能分析人员，你首先需要识别出创

18、立大量短期对象的方法。这些方法是进一步做 削减创立对象数量分析的抱负入手点。JProbe Memory Debugger 供给的一个垃圾监视功能可以把对象和安排它们的方法连接起来，并且当你的应用运行时，可以追踪有多少对象已经被 垃圾回收了。3.1.1 启动 JProbe Memory Debugger 的争论会话1. 启动 JProbe Memory Debugger。当欢送界面消灭的时候，点击“Run“开头启动。图 5JProbe 欢送界面2. 在 JProbe LaunchPad 窗口中:a. 选择“Using Application Server“b. 从“Application Ser

19、ver“下拉的菜单中选择 BEA Weblogic6.1c. 留意在“Integration ID“下拉的菜单中填写 JProbe Demo 13. 选择“Filter“a 点击“Please enter a package ， ormethod to display data for“ 。输入你要调查的包:profiler .quoteme.stockwatchb 在“Display“栏的下拉菜单里选择“Display“4. 选中“Monitor Garbage Collections from Program Start“复选框。5. 选择“Snapshot Directory:“为 d:

20、temp。6. 点击“Run“按钮。图 6JProbe LaunchPad Pad 窗口当 WebLogic Server 初始化时，Runtime Heap Graph 将增高，这反映了对象创立和垃圾回收活动。一旦 WebLogic Server 已经被充分初始化后，你就可以开头着手分析了。3.1.2 运行时交互一旦 WebLogic Server 已经充分初始化，选择你想要用于分析对象循环的应用用例。选择Grabage Monitor 标签，按下面的步骤:1. 首先运行一次 Garbage Collection ，回收在 Java 堆中安排的，但不再使用的对象。Garbage Monito

21、r 表随时更反映这些被回收对象的状况。2. 点击“Clear Table“清空 Garbage Monitor 表。3. 运行你的应用用例。当 Java 虚拟机开头垃圾回收时，Grabage Monitor 表将随之更。提示:在 Heap Usage Chart 中查找负载峰值。急剧升降的负载峰值意味着一些对象在被垃圾回收之前只存活了很短的时间。连在一起的一些急剧升降的负载峰值是一个明确的信号，意味 着是一个对象循环问题。4. 在完成你应用用例后，再次运行 Garbage Collection ，回收最终安排但不再使用的对象。3.1.3 分析结果当会话完毕时，Garbage Monitor 中

22、包含了已回收最多实例的前十个类。通常，这些类不是你自己应用的类，准确地说，它们是被你的一些方法(直接地或间接地)安排的第三方的类。最 后一列是安排这些已回收对象的方法名。提示:假设被不同方法安排的实例属于同一个类，并且都是前十个类的话，你将见到两行一样 的类。1. 使用 Filter Allocating Methods，只显示你包中的一些方法，屏蔽掉其它包中的方法。在我们的例子中，客户 J2EE 应用定义在 profiler .quoteme.stockwatch 包里面，所以我们把过滤标准 profiler .quoteme.stockwatch.*.*输入到 Filter Allocat

23、ing Methods 文本输入掌握中。2. 在 GC”ed 列中，你能看到你的方法安排了多少实例。作为比较，查看Alive 列就能看到还有多少实例仍在堆中。Java 开发者通常会对创立和移走了多少对象而感到惊异。3. 现在你已经识别到你有问题的方法。想想你可能怎样修改这些安排对象的方法，从而削减 或排解对象循环？例如，你可以尝试重用某个对象或者创立一个可重用的对象池。4. WebLogic Server6.1 编译 JSP 后，自动产生了一个 servlet 类名，并赐予一个包名和类名。例如，假设有一个名为 TestJSP.jsp的 JSP 文件，将被编译成名为 jsp_servlet. t

24、estjsp 的类(JSP 名跟着两个下划线，并且都是小写字母)。用 Filtering Classes 为 jsp_servlet.*限制 Garbage Monitor 中的内容，可以看到已经被垃圾回收到 Garbage Monitor 中的 JSP 。在 Filtering Allocating Methods 设置 jsp_servlet.*.* 或jsp_servlet._.* 限制Garbage Monitor 中的内容，可以从安排的角度在指定的 JSP 中查看垃圾回收对象。更深入的争论假设你安排的方法没有一个消灭在 Garbage Monitor 中，或者在修改明显的问题后，仍旧

25、有对象循环的问题；你需要进展堆栈跟踪，检查哪个方法的调用导致了创立实例并安排了空间。 需要使用 heap snapshot 查看堆栈跟踪。要了解更多的信息，请看在线帮助里的Garbage Collection Tutorial 或者 JProbe Memory Debugger Developer”s Guide。3.2 性能分析解决对象循环问题有助于性能的改进，但你可能仍旧面临着性能瓶颈。进展一次性能分析可 帮助你在 J2EE 应用中识别低效率的算法。JProbe Profiler 供给了应用的方法级和源代码行级度量值。3.2.1 启动 JProbe Profiler 调查会话。1. 启动

26、JProbe Profiler。当欢送界面消灭时，点击“Run“开头。图 8 JProbe 欢送窗口2. 在 JProbe LaunchPad 窗口中:a. 选择“Using Application Server“b. 从 Application Server 下拉菜单中选择 BEA Weblogic6.1c. 留意在 Integration ID 下拉菜单中填 JProbe Demo 13. 选择 Filtera. 点击 Please enter a package，class，or method to display data for。输入你要调查的包profiler .quoteme.s

27、tockwatchb. 从 Detail Level 列的下拉菜单中选择 Line Lever这个元素定义了我们想要把全部运行在环境中的 Java 软件看作根底构造。由于我们不想具体了解它们的性能信息 (我们只是想知道在代码上的影响，我们不想更细地分析)提示:在 WLS6.1 中的 JSP Profiling 当 JSP 被 WebLogic Server6.1 编译时，产生的 servlet 被赐予一个产生的包和类名。例如，假设有一个名为 TestJSP.jsp的 JSP 文件，它被编译后，生成名为 jsp_servlet._testjsp 的类(两个底线被 JSP 名跟着，都是小写字母)。

28、 假设你想跟踪你的JSP 里的方法在执行中花了多少时间，你必需指定正确的过滤策略，用于捕获数据。4. 选择“CPU Time“5. 选择“Record Performance at Program Start“复选框6. 选择“a Snapshot Directory:“为 d:temp7. 点击“Run“按钮图 9 JProbe Profiler LaunchPad 窗口3.2.2 运行时交互在性能分析中，Heap Usage Chart 就象一个执行进度的监视器，与上节介绍的 Garbage Monitor不同，这里不供给类似的运行时性能信息。使 WebLogic Server 自己初始化

29、到完全启动。作为对象循环分析，我们推举使用应用级的，以用例为中心的方法进展性能分析，具体如下:1. 清空累积的性能数据 。2. 运行你的应用用例。3. 执行一次性能快照 ，保存性能信息。性能快照包括时间和在用例运行期间对象创立等度量数据 (这个运行期间从重设置性能信息开头-第一步，始终到执行快照完毕，第三步)。3.2.3 解释结果JProbe Profiler 供给两个工具，以不同的格式显示收集到的数据；可依据具体状况选择: Method List 是指以表的形式显示与方法有关的数据信息。使用 Method List 可以依据名称或度量值排序，或显示只显示其中局部方法。Call Graph-是

30、指以有向图的形式显示方法。可以使用 Call Graph 查看并跟踪程序中方法间的调用关系。从 Method List 或 Call Graph 中，你能使用下面这些工具深入到更多的细节数据。Method Detail View 是指对于所选的方法，显示它们是被哪些方法(也称父方法)调用了或它们调用了哪些方法(也称子方法)。Source Window 显示所选方法的语句级性能信息。3.2.3.1 Time and Object Creation MetricsJProbe Profiler 在方法方面收集了三个根本度量值:Number of Calls 是指在会话期间该方法被调用的次数Meth

31、od Time 是指执行该方法所花费的总时间Method Objects 是指该方法创立的对象总数在这些根本的度量值根底上，JProbe Profiler 计算出两种度量值表示方法调用树:Cumulative Time 是指执行这些方法的时间，和执行它们直接或间接调用的方法所花费时间的总和。Cumulative Objects 是指这些方法创立的对象，和这些方法直接或间接调用其它方法创立的对象的总合基于 Number of Calls 用四种平均度量值:Avg.Method Time 是指调用方法的时间除以调用次数Avg.Method Objects 是指方法对象除以调用次数方法对象指方法执行

32、期间创立的对象数， 不包括派生对象创立的数 Avg.Cumulative Time 是指累积时间除以调用次数 Avg.Cumulative Objects 是指累积对象除以调用次数在默认状况下，Call Graph 显示的数据是在性能快照中的数据。我们建议你关闭 Call Graph一会再翻开 Method List 窗口。3.2.3.2 Method ListMethod List 窗口(见图 10)以表的形式显示性能数据。图 10 JProbe Profiler Method List 窗口每一行显示了方法的时间和方法创立对象的度量值。使用 Method List 能很快识别你最耗时的方法

33、。通常你会觉察你的性能瓶颈和这些方法有关。假设你是第一次调查，跟着下面这些步骤将使你能更有效地使用 Method List。1. 选中你的 snapshot，翻开“Method List“。2. “Filter“区域只用于显示在你包中或在你感兴趣的类中的方法。3. 点击“Method Time“列名，把你最消耗时间的方法排在最前面。认真查看前十个。是不是有一些度量值令你惊异?你能改进你方法中的算法吗?4. 点击“Cumulative Time“列名，把最消耗时间的调用树排在最前面。比较一下“Method Time“ 和“Cumulative Time“。虽然方法本身可能效率很高，但也可能调用了

34、低效率的方法，这些低效率的方法可能在你的代码中，或者在第三方的包或应用框架中。5. 点击”Number of Calls”列名，查看一下你哪个方法被调用最多。假设一个或多个度量值同时反映这些方法是低效率的，需要考虑削减调用这些方法，或调用那些效率稍好的方法。3.2.3.3. Call GraphCall Graph(见图 11)供给一个格外有力的方法调用关系视图。它把 J2EE 应用放到 WebLogic Server 上下文环境中，所以你能看到 WebLogic 启动的全部线程，包括调用 J2EE 应用的线程。为了便利查找，Call Graph 下面有“Method List“。当分析性能时

35、，在定位 J2EE 应用的入口点和排解与 WebLogic 线程有关的数据方面， Call Method 是最有效的。在分别出应用的数据根底上，可快速画出执行流程，并用图形清楚地显示出来。下面是使用 Call Method 的有效技巧:1. 选中你的 snapshot，翻开“Call Graph“ 。2. 点击“Find“并且定位你的 J2EE 应用的入口位置。 通常是 servlet 中的 doGet或 doPost方法。3. 选择方法并分别出数据形成图形 。4. 显示方法的一个子集作为开头，这些方法依据“Cumulative Time“排序是最耗时的方法。当你分析一个方法，在方法的调用树上

36、将增加额外的节点。5. 在“Method List“中，依据你觉察的瓶颈位置，在“Color By“的下拉列表中选择一样度量值。依据你选择的度量值，现在最耗时的方法都以明媚的颜色突出显示出来。6. 选择最耗时的方法。开放父方法树(通过点击节点局部或节点左边局部的空箭头记号)，就 能看到哪个方法调用它了。你可以调用不同的，耗时比较少的方法吗 ?你需要常常调用这些方法吗?7. 开放子方法树(指向节点的右边)，可以看到调用了哪个耗时的方法。还有哪些子方法也是 耗时的呢?你意识到第三方的方法实际的耗时状况吗 ?你能调用一个实现了更有效率算法的不同方法吗?图 11 JProbe Profiler Cal

37、l Graph 窗口3.2.3.4 Method Detail View从 Method List 或 Call Graph 中，你都能深入地分析，在一个视图中很便利地看到耗时的方法的度量值，还有它们子方法和父方法的度量值。选择方法并翻开“Method Detail View“ 。“Method Detail View“(见图 12)在窗口的中心显示了选择方法，它的父方法在上面，它的子方法在下面。我们对列的头部已经生疏了，它们和你在其它工具中看到的度量值一样。一个重 要的区分是：用于显示父方法和子方法度量值表示对所选方法的奉献值，不是对它们自己的 度量值。所以，假设一个方法被调用了 12 次，

38、这些调用它的方法，和 12 次调用分别显示在父方法的图中。假设你想连续分析父方法或子方法，双击该方法，使该方法在“Method Detail View“的中心显示。图 12 JProbe Profiler Method Detail 窗口3.2.3.5 Source Window要查看你方法中的代码，选择方法并且翻开 Source Window。你需要指出你的源代码具体位置。假设你是按行收集数据，你能在 Source Window(见图 12)中看到这些数据。在左列中，显示了每条语句的数据度量值。行级度量值是方法级度量值的细化，包括调用次数，执行该行的 时间，执行该行时创立的对象数量，累积时间和累计对象数量。提示:假设需要编辑你的代码，并且已经把集成开发环境 IDE 和JProbe Profiler 集成在一起了， 你可以通过选择 EditEdit Source 翻开你的集成开发环境。固然，需要运行你重写的代码， 并建立的 JProbe Profiler 分析会话时，你做的转变才反映在 JProbe Profiler 上。图 13 Jprobe Profiler Source Window