一步步優化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的部署模型。另外一種可能是，應用程式有修改或者需要重新設定應用程式的效能需求。
對於一些應用以及它們的系統需求來說，需要迴圈幾次這樣的操作，直到應用責任人對應用的效能滿意為止。
假設
這個一步步的優化步驟，是基於應用都有以下執行過程的假設：
1、初始化階段——初始化重要的資料結構和其他需要使用的依賴庫。
2、穩定階段——應用消耗大部分的時間執行其核心函式。
3、可選的總結階段——比如需要製作報告。
穩定階段是我們需要主要關注的地方。
測試基礎設施：
為了做出關於記憶體佔用、延遲、吞吐量以及啟動時間等優化有根據的決定，並且為了證實選擇的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會在接下來