原文：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會在接下來的一節中講到。