JVM優化配置指導手冊
本文向大家簡單介紹一下JVM優化配置的概念，通常情況下是不建議在沒有任何統計和分析的情況下去手動配置JVM的參數來調整性能，因為在JVM5以上已經作了根據機器和OS的情況自動配置合適參數的算法，基本能夠滿足大部分的情況。
JVM優化配置
這里首先要說明的是這里提到的JVM是Sun的HotSpotJVM5和以上的版本。性能優化在應用方面可以有很多手段，包括Cache，多線程，各種算法等等。通常情況下是不建議在沒有任何統計和分析的情況下去手動配置JVM的參數來調整性能，因為在JVM5以上已經作了根據機器和OS的情況自動配置合適參數的算法，基本能夠滿足大部分的情況，當然這種自動適配只是一種通用的方式，如果說真的要達到***，那么還是需要根據實際的使用情況來手動的配置各種參數設置，提高性能。
JVM能夠對性能產生影響的***部分就是對于內存的管理。從jdk1.5以后內存管理和分配有了很多的改善和提高。內存分配以及管理的幾個基本概念和參數說明：
◆JavaHotspotMode：
server和client兩種模式，如果不配置，JVM會根據應用服務器硬件配置自動選擇模式，server模式啟動比較慢，但是運行期速度得到了優化，client啟動比較快，但是運行期響應沒有server模式的優化，適合于個人PC的服務開發和測試。
◆GarbageCollectorPolicy：
在Jdk1.5的時候已經提供了三種GC，除了原來提供的串行GC（SerialGC）以外，還提供了兩種新的GC：ParallelGC和ConcMarkSweepGC。ParallelGC采用了多線程并行管理和回收垃圾對象，提高了回收效率，提高了服務器的吞吐量，適合于多處理器的服務器。
◆ConcMarkSweepGC
采用的是并發方式來管理和回收垃圾對象，降低垃圾回收產生的響應暫停時間。這里說一下并發和并行的區別，并發指的是多個進程并行執行垃圾回收，那么可以很好的利用多處理器，而并行指的是應用程序不需要暫停可以和垃圾回收線程并發工作。串行GC適合小型應用和單處理器系統（無需多線程交互，效率比較高），后兩者適合大型系統。
使用方式就是在參數配置中增加-XX:+UseParallelGC等方式來設置。
對于這部分的JVM優化配置在網上有很多的實例可以參考，不過最終采用哪一種GC還是要根據具體的情況來分析和選擇。
Heap：
OOM的各種經歷已經讓每一個架構師開發人員看到了了解Heap的重要性。OOM已經是Heap的臨界點，不得不引起注意，然而Heap對于性能的潛在影響并未被引起重視，不過和GC配置一樣，在沒有對使用情況作仔細分析和研究的情況下，貿然的去修改Heap配置，可能適得其反，這里就來看一下Heap的一些概念和對于性能的影響。
我們的應用所能夠得到的***的Heap受三部分因素的制約：數據處理模型（32位或者64位操作系統），系統地虛擬內存總數和系統的物理內存總數。首先Heap的大小不能超過不同操作系統的進程尋址范圍，當前大部分系統***限度是4G，Windows通常是2G，Linux通常是3G。系統的虛擬內存也是分配的依據，首先是不能超過，然后由于操作系統支持硬盤來做部分的虛擬內存，如果設置過大，那么對于應用響應來說勢必有影響。再則就是要考慮同一臺服務器上運行多個Java虛擬機所消耗的資源總合也不能超過可用資源。就和前面OOM分析中的一樣，其實由于OS的數據處理模型的限制，機器本身的硬件內存資源和虛擬內存資源并不一定會匹配，那么在有限的資源下如何調整好資源分配，對于應用來說尤為重要。#p#
JVM優化配置中關于Heap的幾個參數設置：
說了Heap的有限資源問題以后，就來看看如何通過配置去改變JVM對于Heap的分配。下面所說的主要是對于JavaHeap的分配，那么在申請了JavaHeap以后，剩下的可用資源就會被使用到NativeHeap。
Xms:javaheap初始化時的大小。默認情況是機器物理內存的1/64。這個主要是根據應用啟動時消耗的資源決定，分配少了申請起來會降低啟動速度，分配多了也浪費。
Xmx:javaheap的***值，默認是機器物理內存的1/4，***也就到1G。
這個值決定了最多可用的JavaHeapMemory，分配過少就會在應用需要大量內存作緩存或者零時對象時出現OOM的問題，如果分配過大，那么就會產生上文提到的第二類OOM。所以如何配置還是根據運行過程中的分析和計算來確定，如果不能確定還是采用默認的配置。
Xmn:javaheap新生代的空間大小。
在GC模型中，根據對象的生命周期的長短，產生了內存分代的設計：青年代（內部也分成三部分，類似于整體劃分的作用，可以通過配置來設置比例），老年代，持久代。每一代的管理和回收策略都不相同，最為活躍的就是青年代，同時這部分的內存分配和管理效率也是***。通常情況下，對于內存的申請優先在新生代中申請，當內存不夠時會整理新生代，當整理以后還是不能滿足申請的內存，就會向老年代移動一些生命周期較長的對象。
這種整理和移動會消耗資源，同時降低系統運行響應能力，因此如果青年代設置的過小，就會頻繁的整理和移動，對性能造成影響。那是否把年青代設置的越大越好，其實不然，年青代采用的是復制搜集算法，這種算法必須停止所有應用程序線程，服務器線程切換時間就會成為應用響應的瓶頸（當然永遠不用收集那么就不存在這個問題）。老年代采用的是串行標記收集的方式，并發收集可以減少對于應用的影響。
Xss:線程堆棧***值。允許更多的虛擬內存空間地址被JavaHeap使用。上面介紹了一下關于JVM優化配置的理論知識，下面看一下幾個例子。
以下是sun公司的性能優化白皮書中提到的幾個例子：
1．對于吞吐量的調優。機器配置：4G的內存，32個線程并發能力。
java-Xmx3800m-Xms3800m-Xmn2g-Xss128k-XX:+UseParallelGC-XX:ParallelGCThreads=20
-Xmx3800m-Xms3800m配置了***JavaHeap來充分利用系統內存。
-Xmn2g創建足夠大的青年代（可以并行被回收）充分利用系統內存，防止將短期對象復制到老年代。
-Xss128減少默認***的線程棧大小，提供更多的處理虛擬內存地址空間被進程使用。
-XX:+UseParallelGC采用并行垃圾收集器對年青代的內存進行收集，提高效率。
-XX:ParallelGCThreads=20減少垃圾收集線程，默認是和服務器可支持的線程***并發數相同，往往不需要配置到***值。
2．嘗試采用對老年代并行收集
java-Xmx3550m-Xms3550m-Xmn2g-Xss128k-XX:+UseParallelGC-XX:ParallelGCThreads=20-XX:+UseParallelOldGC
-Xmx3550m-Xms3550m內存分配被減小，因為ParallelOldGC會增加對于NativeHeap的需求，因此需要減小JavaHeap來滿足需求。
-XX:+UseParallelOldGC采用對于老年代并發收集的策略，可以提高收集效率。
3．提高吞吐量，減少應用停頓時間
java-Xmx3550m-Xms3550m-Xmn2g-Xss128k-XX:ParallelGCThreads=20-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:SurvivorRatio=8-XX:TargetSurvivorRatio=90-XX:MaxTenuringThreshold=31
-XX:+UseConcMarkSweepGC-XX:+UseParNewGC選擇了并發標記交換收集器，它可以并發執行收集操作，降低應用停止時間，同時它也是并行處理模式，可以有效地利用多處理器的系統的多進程處理。
-XX:SurvivorRatio=8-XX:MaxTenuringThreshold=31表示在青年代中Eden和Survivor比例，設置增加了Survivor的大小，越大的survivor空間可以允許短期對象盡量在年青代消亡。
-XX:TargetSurvivorRatio=90允許90%的空間被占用，超過默認的50%，提高對于survivor的使用率。
類似的例子網上很多，這兒就不在列下來了，最終是否采取自己配置來替換默認配置還是要根據虛擬機的使用情況來分析和配置。
【編輯推薦】
