DevPartner Java版 实践手记
写在前面的话
在Google上搜索 “软件开发 论坛”，用时0.1秒，共有63万条左右的记录；搜索“Java 论坛”，用时0.21秒，共有630多万条搜索结果。
通过百度搜索上述两个关键字，分别给出1800和3020个网页，用时都不超过0.1秒。
想起刚上大学那会儿，Java还是只属于少数技术潮人的宠儿，学术界则在争论Java技术和C++技术在实际应用中孰优孰劣。Java既有坚定的拥护者，也有彻底的反对者，不久之后XML更以颠覆者的姿态出现，非常之热闹。那个时候Google在哪儿呢？可能还在美国的襁褓中吧，反正远在中国的我尚未感应到它的存在，更无从提供权威的搜索结果了。百度？对不起，那个时候我只知道那句意境很美的词“众里寻她千百度”。
技术的发展，持续挑战着程序员想象空间。Java和C++和谐共处，C++这颗老树不仅长青，而且开出新花C#。Java技术的全面开花更是让人眼花缭乱：AWT、SWING、JSP、EJB、J2EE、J2ME、Struts、Hibernate、SOA、Beehive、Ruby … 大的趋势显而易见：技术理念越来越清晰简单，开源代码越来越多，找出代码存在的问题却变得越来越困难。大浪淘沙，集成开发工具和测试工具就只剩下为数不多的几个：Eclipse、JBuilder、WebLogic Workshop、NetBeans IDE、Ant、Junit、DevPartner Java Edition (以下简称DPJ)，尤其是对Java代码进行质量保证的开发工具，就只剩下Compuware公司的DPJ。
Java的资深玩家肯定都听说过大名鼎鼎的NuMega，1997年，NuMega和Compuware联姻，DevPartner就是其中一份厚厚的嫁妆。十多年过去了，它随着Java技术的演进而同步成长，陪伴程序员走过一路的风风雨雨，一如它的名字所阐述的，DPJ是Java程序员的忠实伙伴。
在线实例PetStore简介
在玩转DPJ之前，先了解一下我们的在线实例。PetStore[下载地址：http://beehive.apache.org/docs/1.0.1/samples/petstore.html]是一个小型的网上宠物商店，由著名的Apache 软件组织提供的一组展示技术，意在展示Beehive的最佳实践。
PetStore后端是一个数据库（Derby），它可以部署到Tomcat等Web 服务器上。作为一个典型的J2EE应用，PetStore虽小但五脏俱全，和广大程序员每天真正参与的项目非常之接近，之后我们大部分的实践都会把它作为我们的解剖对象。
性能调优实践
对PetStore这样一个网上宠物商店，一个典型应用场景是：浏览网站，将心仪的宠物放入购物车，然后埋单。为了发现该应用场景中可能存在的性能问题，典型的案例有：
某个用户反复登录PetStore选购宠物，循环执行数百次；
多个用户同时登录PetStore选购宠物，系统持续运行数天；
我们以第一个案例为例来看如何使用DPJ进行性能调优。
1、启动测试
通过DPJ提供的管理工具，可以将支撑PetStore的Tomcat服务器纳入调优范畴，如图1.1所示。
图1.1：DPJ的测试启动界面
在开始测试之前，我们需要通过“Configuration Tab”页提供的配置工具创建自己的配置文件“Demo_configure”，来确保DPJ采集我们感兴趣的各种数据[ 详细的参数设置请参考DPJ的在线帮助]。
配置完成后，进入“Application Server Testing Tab”页，选定“Demo_configure”，并在“Analysis Type”下拉框中选中“Performance”，找到对应的应用服务器“Administrator:TomcatService”，点击“Start”，我们的测试就开始了！
2、实时审阅运行中的系统
启动之后，DPJ自动进入图2.1。稍候片刻我们就可以登录PetStore，执行我们的测试案例。当系统进入稳定运行阶段，线程的生存状况就如图2.2所示。通过这个实时更新的窗口，我们可以查看线程的创建、繁忙、空闲、阻塞、消亡。
图2.1：系统启动阶段线程的生存状况
图2.2：系统正常运行阶段线程的生存状况
在测试案例执行的过程中，若发现线程阻塞问题，或着页面响应时间开始变慢，随时都可以点击“View Results”，DPJ则会即刻提供一份到此刻为止的系统性能分析报告。值得注意的是，DPJ的数据收集工作并不会因此而终止，它会持续进行，直至我们手工终止该测试会话。
3、分析和评估性能诊断报告
DPJ最大亮点是它提供了一份详尽的性能诊断报告，帮助我们从多个角度深入分析系统存在的性能问题。在这份报告中，DPJ会根据严重程度对问题进行排序，我们自然而然就会将主要精力放在最关键问题的深入分析和解决上。
（1）快速浏览测试报告，找出关键问题
在性能报告的结果汇总中，我们可以轻松找到相应速度最慢的接入点（Entry Point）、占用线程时间最多的API和方法、以及等待时间最长的方法，分别如图3.1.1、3.1.2和3.1.3所示。
图3.1.1：响应速度最慢的接入点
图3.1.2：占用线程时间最多的API和方法
图3.1.3：等待时间最长的方法
对比图3.1.2和3.1.3，我们不难发现占用线程时间最多的方法SharedFlow.HandleLogin同时也是等待时间最长的方法，这就意味着该方法的性能有很大的优化空间。
点开图3.1.1中响应最慢的接入点Controller.securityCheck和3.1.2中占用线程时间最多的API Servlet，我们发现它们同样都指向登录模块。
因此我们可以确定：在我们本次执行的测试场景中，最关键的性能问题出现在与数据库交互密切的用户登录过程。
（2）对关键问题进行深入分析
从图3.1.3中点击关键方法SharedFlow.handleLogin查看该方法的性能清单，如图3.2.1所示。
图3.2.1：方法SharedFlow.handleLogin的性能清单
这张性能清单列出了该方法在实际运行时占整个类执行时间的36.91%，共执行4次，首次执行时间为1.18s，最短执行时间为7.28ms，平均执行时间为0.30s，等待时间为0.42s。通过这些数据，我们不难发现该方法之所以“最慢”，有两个主要原因：
首次执行占用时间太长
线程等待时间太长
要将分析和优化思路付诸实践，真正提高应用性能，必须从源代码着手。通过图3.2.1中的超链接，可以进入方法SharedFlow.handleLogin的调用关系图，并浏览该方法的源代码，分别如图3.2.2和3.2.3所示。
图3.2.2：方法SharedFlow.handleLogin的调用关系图
在图3.2.2中，以红色高亮显示的关键路径上，我们可以看到调用该方法的接入点正是图3.1.1中相应最慢的接入点，从而印证了我们最初的分析。
图3.2.3：方法SharedFlow.handleLogin的代码清单
通过图3.2.3的代码清单，我们可以看到该方法之所以慢，主要是因为它把96.79%的时间花在了以黄色高亮凸显的这行代码上，这就是我们本次优化的焦点所在！
值得注意的时，从不同的角度执行深入分析，系统所呈现的向导和图标可能有所不同，但最终都会提供调用关系图，并直接定位到代码行，从而使得性能优化迅速而高效。由于篇幅所限，其他的调优路径留给有兴趣的读者自己去探索。
4、终止测试会话
测试案例执行结束后，我们可以回到DPJ的主界面，终止当前测试会话，如图4.1所示。
图4.1：终止当前测试会话
这里有两个选择：“Detach”和“Stop”。选择“Detach”，则Tomcat会继续运行，我们之后还可以选择“Attach”快速启动其他类型的测试会话；若点击“Stop”按钮，则不但当前测试会话会终止，Tomcat服务器也会被关闭。
5、性能调优小结
DPJ的实时监测和性能报告使得性能问题的优化变得一目了然，清晰可见。我们在这里只是用单个用户执行一个典型的场景，就可以轻松找出潜在的性能问题。代码调用关系图和代码清单则让我们快速将性能优化的思路转化为实践。
当调优完成后，DPJ使得性能验证也变得非常容易，只需要重复执行整个测试案例，对比两份测试报告即可。
运行时内存分析
Run-time memory profiling
Background Intro.
Memory issue detection and prioritizing.
Locate root cause via call graph.
Resolve issue and verification.
Closure.
http://news.csdn.net/n/20081016/119979.html