Oracle 融合中間件附帶了一個極好的工具集，用於對可疑應用程序行爲進行分析。
2010 年 1 月發佈
自 1995 年 Java 誕生以來，用 Java 編寫的應用程序變得越來越複雜。隨着時間的推移，人們開發出了許多模型和架構來應對日益複雜的需求。遺憾的是，解決方案不會變得更加輕便容易，而是更爲複雜費力。每增加一個新組件都會增加延遲，從而使解決方案速度更慢。
當速度慢下來時，通常人們總是懷疑所使用的技術。人們懷疑的對象各不相同，可能懷疑數據庫也可能懷疑中間件，這取決於他們的技術背景。人們通常懷疑得最少的是網絡或瀏覽器。當然，不加證明就懷疑所使用的技術是不公平的，而且網絡或瀏覽器可極大地影響速度。
爲了找出耗費時間的真正原因，人們需要在特定的使用情況配置文件環境下對應用程序進行分析並提供無懈可擊的證據。令人慶幸的是，Oracle 融合中間件包含了各種工具以協助您完成上述工作。
常見可能原因
性能低下可能有許多原因。下面是一些可能造成應用程序性能低下的最爲常見的問題：
內存泄漏。內存泄漏 這個術語有點誤導。儘管您的計算機或 JVM 中的內存不會象水一樣“泄漏”，但隨着時間的流逝，您會注意到可用內存會比預期的少。既然 JVM 垃圾回收器 (GC) 通過從內存中刪除不使用的對象來收回不使用的內存，爲何還會出現這種情況？這很可能是因爲，有些可從內存中刪除的對象因其沒有表現爲未使用而不能被 GC 所發現。
大多數的內存泄漏是由於被遺漏的引用或實現不良的自生緩存而引起。（提示：如果您不使用軟引用或弱引用，就不能利用 GC 來自動縮減緩存。）這些泄漏會增加 GC 的調用次數及其發現要釋放的少量內存所需的時間。這樣導致的應用程序開銷會影響用戶的體驗。找出並消除這些內存泄漏的情況是性能調優的主要目標。
數據建模不良。數據建模對應用程序的運行時行爲有極大的影響。我們應該知道，在現代的多層應用程序中，數據能夠並且會跨越進程邊界。跨越這些邊界需要花費時間，因爲須將二進制形式的數據轉換爲一種傳輸格式。然而，隨着這種序列化和反序列化過程的實現，比起數據待在進程內的情況，程序速度變得更慢了。所使用的數據類型以及實現該過程的方式對整體性能有着極大的影響。
例如，日期或時間戳通常保存爲 64 位的值（Java 的 Long 類型）。然而，選擇用 Calendar 類型來保存此類信息也沒有問題。Calendar 類型一般會佔用 80 個字節。因此，通過選用合適的類型來保存時間戳信息，可以輕鬆節省 72 個字節。
另外，相比於非序列化，選擇外化可極大地提高性能。缺點是外化會爲開發期間高度緊迫的編程實踐帶來額外的成本開銷。
網絡輸入/輸出流量較高有關網絡計算的一個謬論是，“快速的”網絡。一旦您需要進行遠程調用，那麼絕對會更爲費時。減少網絡調用的次數或大小都可節省應用程序所需時間以供他用。
節省網絡時間相當容易。其中一個方法是，讓遠程應用程序完成自己的工作。一般來說，非常具體的調用只返回一個正確結果，與那些返回數千個不需要的結果的調用相比，顯然更爲快速。
JVM 配置不良。每個 JVM 都可通過許多命令行開關來配置，其中許多開關會直接或間接地影響應用程序的運行時行爲。例如，幾乎每個 JVM 用戶都知道用於定義 JVM 內存大小（或稱爲“堆”）的開關。而其他開關不太爲人所熟知，但恰當地設置這些開關，可以在特定的使用情況配置文件環境下提高性能；然而，在另一個不同的使用情況配置文件環境下，同樣的設置也可能會降低性能。
數據庫速度慢。在一個多層架構中，數據庫速度慢是一個不當託詞。相反，在應用程序架構的龐大組織中，數據庫幾乎總是速度最快的那部分。另一方面，缺失索引可極大地降低性能。數據庫經過充分調優，SQL 語句使用恰當，這兩者一起有助於實現最佳的架構。
現在我們已瞭解了導致性能降低的一般可能原因，接下來我們要做什麼？爲了能夠提供證據來說明性能降低是由其中某個原因導致的，在合適的時間使用合適的工具是很重要。但在我們瞭解這些工具之前，先了解一下可用於 Oracle 融合中間件的運行時環境。
Oracle 融合中間件中的 Java 虛擬機
安裝 Oracle WebLogic Server 作爲大多數配置的基礎時，您可以決定要使用哪種 JVM。截至撰寫本文時，隨取隨用的 WebLogic Server 提供 Sun JVM 1.6 或 Oracle JRockit JVM 1.6。每種 JVM 都有自己的特質，適用於特定的應用程序配置文件。哪種 JVM 最適合您的應用程序取決於應用程序配置文件以及 JVM 處理該配置文件的方式。要找出最適合您的應用程序配置文件的 JVM，進行全面的測試和調優是非常重要的。
Sun JVM
Sun JVM 是 Java 參考實現，應該用它來驗證應用程序是否按照預期運行。
Sun JVM 的內存模型包含兩個主要的內存區域：年輕代 和年老代。年輕代區域又分爲一個 Eden 空間 和兩個存活空間。另外，還有一個可用的持久代 (PermGenSpace)。
動態創建的對象開始時存放於 Eden Space 中。在垃圾回收期間，這些對象移至存活空間然後再移至年老代，直到它們因未被使用而被 GC 回收。PermGenSpace 存儲靜態數據，如類、常量值和靜態變量。
如果 PermGenSpace 很小，其中卻加載了過多的類、靜態變量和常量值，Sun JVM 可能很快就會用光內存。由於 PermGenSpace 是從整體堆容量中獲取其空間的，其空間一定相當小。當年老代持續佔用可用空間的 70-80% 時，我們就可以認爲發生了內存泄漏。而當佔用了 90% 時，情況就非常嚴重了，應立即進行分析。
高度飽和的內存使用會影響運行時，因爲此時對 GC 的調用會更爲頻繁並且 GC 需要更長的週期時間才能找到可回收的區域。這些區域通常過小，GC 需要更多的週期來完成內存請求。當情況變得越來越糟時，JVM 只能執行 GC，因而應用程序掛起。
Sun JVM 附帶有各種 GC。每種 GC 對於特定的使用情況配置文件來說都是完美的。有關可用 GC 的詳細信息，可參閱 JVM 文檔。可通過命令行開關來調優 GC 及其行爲。
Oracle JRockit JVM
Oracle JRockit JVM 是一個 Java 兼容實現，其設計旨在實現針對 Intel 硬件的非常快速的 JVM。JRockit 的內存模型類似於 Sun JVM 的內存模型，它也有年輕代和年老代區域。新對象和存活時間尚短的對象存放於年輕代區域中，而存活時間較長的對象可存放於年老代區域中。Oracle JRockit 內存模型沒有 PermGenSpace，因此不會因 PermGenSpace 飽和而引發任何內存不足之異常情況。
Oracle JRockit JVM 同樣提供各種 GC。特別是爲了獲得更佳的運行時行爲，值得嘗試併發標記掃描 GC 和並行標記掃描 GC。就 Sun JVM 而言，這些 GC 可通過命令行開關來明確地設置，並且它們是應用程序使用情況配置文件的優化配置中的一部分設置。
現在，您對 Oracle 融合中間件 JVM 有了些基本瞭解，下面我們將概要介紹用於診斷性能問題的基本工具集。根據您所採用的 JVM，可以使用不同的工具組合。
Oracle Enterprise Manager
爲了發現性能問題，您應該始終從 Oracle Enterprise Manager Fusion Middleware Control 控制檯開始。此管理軟件可隨大多數組件安裝，因此可能已經可以使用了。它會顯示應用程序的運行時狀況的有關重要信息。
該管理控制檯的 Summary 屏幕顯示實例的當前狀態彙總。除了 Response and Load 圖形外，您還應仔細看看 Summary portlet。這個 portlet 在非常小的屏幕區域上顯示可行信息。所顯示的信息對於任何 Java EE 應用程序都非常重要，因爲其中包括 Servlet/JSP、JMS、EJB 以及 JDBC 和 JTA 使用情況指示器。
圖 1 Summary 屏幕
如果您的應用程序使用了大量的 Servlet 和 JSP，則下面的 Most Requested portlet 值得一看。如果響應時間長得離譜，則表示性能不佳。
圖 2 Most Requested portlet
而且，永遠不要低估日誌文件的作用！日誌文件是您尋找各種問題指示的第一場所。時間和空間方面的其他引用結合使用，您可以輕鬆獲得對應用程序的運行時行爲的更好了解。下面的屏幕截圖顯示 Log Messages 搜索窗口。
圖 3 Log Messages 搜索窗口
使用 VisualVM
VisualVM 和 JVisualVM 工具主要面向 Sun JVM。自 JDK 1.6.0_10 以來，JVisualVM 成爲 JDK 的一部分，而 VisualVM 則可作爲獨立的應用程序單獨安裝。這兩個工具有相同的基礎並且都可通過插件進行擴展，VisualVM 可更好地支持更多的插件。VisualVM 可用於 JDK 版本 1.5.0 以及更高版本，但在用於版本 1.6.0 時確實表現更佳。
每個分析均從 VisualVM 控制檯開始。這會以非常整潔的方式顯示所有運行時參數（無需挖掘某些啓動腳本）。只需單擊 Monitor 選項卡即可顯示 JVM 的當前狀態。Threads、Profiler、Memory Sampler 或 Visual GC 選項卡中顯示更多詳細信息。
圖 4 VisualVM 控制檯窗口
圖 5 VisualVM 中的 VisualGC
VisualGC。當需要找出與 Sun JVM 內存模型有關的問題時，可選擇使用 VisualGC 插件。在 jvmstat 3.0 for JDK 1.5.0 附帶的 VisualGC 工具的基礎上，此插件以其 Class Loader Time、Compile Time（針對 JIT）和 GC Time 顯示 JVM 的所有聯機狀態。如果應用程序不久之後變得越來越慢，您應考慮使用 VisualGC 對 JVM 內存進行分析！
圖 6 VisualVM 的 Threads 選項卡顯示所有線程的狀態。
內存抽樣和堆轉儲。要分析對象使用可用內存的情況，可以使用兩個工具。Memory Sampler 爲您提供一個聯機內存視圖，而 Heap Dump Analyzer 可用於提供脫機內存視圖。只需按下一個按鈕即可隨時創建堆信息轉儲文件。VisualVM 會自動讀取該轉儲文件並顯示其結果（如下所示）。
圖 7 堆轉儲結果
Oracle JRockit Mission Control
運行 Oracle 融合中間件及其提供的 Oracle JRockit JVM 時，無需進行其他安裝即可使用 Oracle JRockit Mission Control。
和 VisualVM 一樣，從 JRockit 控制檯開始進行分析。該控制檯使用 Used Java Heap、Used Physical Memory、CPU Usage 和 Live Set 量表以及 Memory 或 Processor 使用情況圖形來顯示 JVM 當前狀態的概要信息。可通過 Memory、Threads、Runtime、Exception Count 或 Memory Profile 選項卡進一步深入瞭解應用程序配置文件。
圖 8 Oracle JRockit Mission Control 控制檯
Oracle JRockit Runtime Analyzer (JRA) 現已完全集成到 Mission Control 中，可以用它來根據需要記錄應用程序的運行時行爲。這不需要特殊的技巧，如內存模塊更換、結合或特定共享庫方面的技巧。這會帶來 1-2% 的小開銷。
通過 JRA 可獲得應用程序的一個快照。其中包括速度較慢的方法、內存使用情況、所有現有對象、可能的優化方法以及阻塞線程。
圖 9 Oracle JRockit Mission Control - Top Hot Methods
圖 10 Memory Analyzer — 趨勢分析顯示可能的內存泄漏。
總結
Oracle 融合中間件附帶了一個極好的工具集，用於對可疑應用程序行爲進行分析。這些工具主要用於反映即席使用情況，並非用於連續監視。另外，爲了全面瞭解所有組件的情況，需要一個更爲全面的視圖 — Java (AD4J) 應用程序診斷或 Oracle 實時用戶體驗會是好的選擇。
如果需要對應用程序進行分析，則必須使用模仿引發問題的應用程序配置文件的測試用例。經常運行這些測試用例以全面瞭解您的應用程序。
對應用程序進行調優時，在每步之後執行這些測試並評估其影響。如果程序並未按照預期工作，返回並嘗試進行另一次調優。這需要時間，但最終您將獲得一個針對您應用程序配置文件的調優良好的環境。