一步步優化JVM六：優化吞吐量[轉]

原文：http://ganlv.iteye.com/blog/1571315

參考：http://www.myexception.cn/software-architecture-design/1455594.html

現代JVM是一個具備靈活適應各類應用能力的軟件，儘管不少應用可以在JVM的默認配置下運行良好，可是有些應用仍是須要優化JVM配置以達到其性能要求。因爲各類各樣的應用可以運行在如今JVM上面，因此大量的JVM選項能夠配置來提高應用的性能。不幸的是，對一個應用而言優化得很好的JVM配置，對應另外的應用不必定適合。因此，真正理解怎樣優化JVM配置是很是有必要的。

   優化現代JVM是一門很大的藝術，可是理解和應用一些基本知識可以讓優化JVM的任務變得更加簡單。本章就是介紹這些基本知識和一些常規的步驟去優化Java HotSpot虛擬器。爲了更好的理解本章的內容，你應該對JVM和垃圾回收器有一些基本的瞭解。

   本章以一步步的優化方法包括一些假設開始，在優化JVM以前，你須要先知道怎樣測試應用性能、性能需求、測試的基礎工具以及用來收集數據的垃圾回收器的命令行選項。接下來有幾個章節來講明怎麼樣一步步優HotSpot虛擬器行爲——啓動、內存的佔用、吞吐量、延遲等。

   方法

   下面這張圖片展現了本章要說明的方法。他由一些清晰的應用性能需求開始，這個性能需求應該是應用負責人排過優先級的。與描述計算什麼及輸出什麼的功能層面需求相比較，系統層面需求描述了系統的一些指標，好比：吞吐量、響應時間、內存消耗、啓動時間、可用性以及易管理性等等。

    

 

     

   下一節，咱們仔細看看每項系統指標對優化JVM的重要做用。

   優化JVM性能涉及不少權衡，當你提高某一項性能指標的時候，每每須要犧牲其餘指標。好比說，爲了最少的消耗內存，每每須要以延遲或者響應時間做爲代價。或者，你想要提高應用的易管理性，你須要下降應用的的可用性的級別，因爲可用性的提高是創建在多個JVM上的，多個JVM可用下降一個JVM出錯形成整個應用的沒法使用的風險。因爲有不少的取捨須要作，理解真正性能需求就變得極其重要了，理解需求才可以正確的使用方法。

   一旦你知道了哪一些系統指標是重要的，接下來要作的就是選擇JVM的部署模型，選擇是部署在多JVM上面仍是單個JVM上面。可用性、易管理性以及內存的佔用等系統指標在選擇合適的部署模型的時候都扮演了重要角色。

   接下來就是選擇JVM的Runtime，HotSpot虛擬器提供了聚焦在更快的啓動速度和更小的內存佔用的32位的client虛擬器，以及在32位和64位系統中有更高的吞吐量server虛擬器。系統對吞吐量、響應時間以及啓動時間的需求決定了對JVM Runtime的選擇。

   接下來就是要優化垃圾回收器，以知足系統對內存佔用、延遲以及吞吐量的需求，咱們按照首先內存佔用，其次延遲時間，最後吞吐量的順序來進行優化。

   優化是在不停地測試和調整配置中循環的，須要數次循環以達到性能的需求，另外，也有可能優化了一個點的時候，可是須要回到前面幾個步驟從新進行檢查。好比，假如你在幾回優化垃圾回收器以後，對應用的延遲仍是不滿意，這個時候就有必要調整JVM的部署模型。另一種多是，應用程序有修改或者須要從新設定應用程序的性能需求。

   對於一些應用以及它們的系統需求來講，須要循環幾回這樣的操做，直到應用責任人對應用的性能滿意爲止。

   假設

   這個一步步的優化步驟，是基於應用都有如下執行過程的假設：

   一、初始化階段——初始化重要的數據結構和其餘須要使用的依賴庫。

   二、穩定階段——應用消耗大部分的時間執行其核心函數。

   三、可選的總結階段——好比須要製做報告。

   穩定階段是咱們須要主要關注的地方。

   測試基礎設施：

   爲了作出關於內存佔用、延遲、吞吐量以及啓動時間等優化有根據的決定，而且爲了證明選擇的JVM運行環境是正確的，咱們須要從試驗中收集數據（須要注意的是這個試驗要可以反映生產環境的實際狀況）。所以，有一個可以表明生產環境的性能測試環境就至關重要了。包括硬件和軟件都須要表明生產環境。簡單的說，測試環境和生產環境越接近，作出來的優化決定越靠譜。

   下面，咱們詳細介紹需求的定義。

   性能需求詳細描述：   從前面咱們知道，系統層面的需求決定應用的某一方面的特性，好比它的吞吐量、響應時間、消耗的內存、它的可用性以及易管理性等等。另外，功能需求決定了應用計算的內容或者產生的輸出。

   接下來的咱們描述一下咱們會涉及到層面的需求。

   可用性

   可用性是衡量應用處於可用狀態的指標。可用性需求代表了當應用的某些組件損壞或者遇到錯誤的時候，整個應用或應用的其餘部分處於可用狀態。

   在Java應用領域，高可用性能夠經過把系統的分隔成各個組件，而後運行在不一樣JVM上面或者在多個JVM上面運行相同應用實例來實現。一個須要平衡的點是，當提高系統的可用性，系統的維護成本會升高。引入更多的JVM或者機器，那麼就有更多的JVM須要管理，這個就是形成了成本的升高和複雜性的提高。

   咱們常見的可用性需求例子：「當系統某一部分出現錯誤的時候，不要讓整個應用程序崩潰」。

   易管理性

   易管理性是衡量系統的運行和監控的成本以及配置應用的成本。易管理性的需求代表了這個應用被管理的容易程度。一般來說，用更少的JVM去運行應用，那麼須要付出更小的成本去維護和監控應用。並且更少的JVM應用配置也更加簡單，可是這個是創建犧牲應用的可用性上面的。

   一個簡單的易管理性需求例子：「因爲有限的資源，應用只能部署到儘可能少的JVM上面。」

   吞吐量

   吞吐量是衡量系統在單位時間裏面完成的工做數量。吞吐量需求一般忽略延遲或者響應時間。一般狀況下，提高吞吐量須要以系統響應變慢和更多內存消耗做爲代價。

   一個吞吐量的例子：「這個應用須要每秒完成2500個事務。」

   延遲和響應時間

   延遲或者響應時間是衡量應用從接收到一個任務到完成這個任務消耗的時間。一個延遲或者響應時間的需求須要忽略吞吐量。一般來說，提高應用的響應時間須要以更低吞吐量或提升應用的內容消耗。

   一個延遲或者響應時間的例子:"這個應用會在60毫秒內，執行完成交易操做。"

   內存佔用

   內存佔用是衡量應用消耗的內存，這個內存佔用是指應用在運行在某一個吞吐量、延遲以及可用性和易管理性指標下的內存消耗，內存佔用是一般描述爲應用運行的時候Java堆的大小或者總共須要消耗內存。一般狀況下，經過增長Java堆的大小以增長應用內存佔用能夠提高吞吐量或者減小延遲，或者二者兼具。當應用可用的內存減小的時候，吞吐量和延遲一般會受到損失。在給定內存的狀況下，應用佔用的內存能夠限制應用的實例數（這個會影響可用性）。

    一個例子說明內存佔用的需求是：「這個應用會單獨運行在一個8G的系統上面或者多出3個應用實例運行在一個24G的應用系統上面。」

   啓動時間

   啓動時間是衡量應用初始化的時間（如：eclipse的啓動時間）。在Java應用中，你們可能對JVM優化應用的熱點須要的時間感興趣。Java應用初始化須要消耗的時間依賴於不少因素包括單不只限於須要裝載的類的數量、須要初始化的對象數量、而且這些對象怎麼初始化，以及HotSpot虛擬器運行環境的選擇（client or server，eclipse使用的HotSpot Client，Jboss會使用HotSpot Server,二者在初始化時間上和運行過程當中對熱點的優化不同）。

   拋開須要加載的類的數量、須要初始化的對象的數量以及對象如何初始化，使用HotSpot client運行環境會得到更快的啓動速度，因爲他沒有作足夠的優化，這些優化能夠提供更高吞吐量和更低的延遲。相反，HotSpot Server運行環境須要更長的啓動時間，因爲它須要更好多的得到應用關於Java代碼的信息，而且對生成的機器碼進行了很高優化。

   啓動時間需求的例子如：「這個應用會再15秒內完成初始化。」

   

   對系統需求進行優先級排序

   優化操做的第一步就是對系統層面的需求進行優先級排序。作這個須要把主要的應用負責人叫到一塊兒來商定優先級的排序，而且最終達成一致。這個討論須要在應用的架構和設計階段完成，因爲這個討論能夠提供很是明確的結論，好比說：什麼系統需求是最重要的。

   對於應用的負責人來講，系統需求的優先級決定了優化操做。最重要的系統需求促使造成一些基本決定。好比說：可用性比易管理性重要，那麼JVM部署模型就會採用部署多個JVM。相反若是易管理性比可用性重要，那麼就更加傾向於選擇單個JVM的部署模型。

   如何選擇JVM部署模型和JVM Runtime會在接下來的一節中講到。