寫在前面的話
在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