1.GC相關
HotSpot虛擬機將其物理上划分為兩個–新生代（young generation）和老年代（old generation）。
新生代（Young generation）: 絕大多數最新被創建的對象會被分配到這里，由於大部分對象在創建后會很快變得不可到達，所以很多對象被創建在新生代，然后消失。對象從這個區域消失的過程我們稱之為”minor GC“。
老年代（Old generation）: 對象沒有變得不可達，並且從新生代中存活下來，會被拷貝到這里。其所占用的空間要比新生代多。也正由於其相對較大的空間，發生在老年代上的GC要比新生代少得多。對象從老年代中消失的過程，我們稱之為”major GC“（或者”full GC“）
圖中的持久代（ permanent generation ）也被稱為方法區（method area）。他用來保存類常量以及字符串常量。因此，這個區域不是用來永久的存儲那些從老年代存活下來的對象。這個區域也可能發生GC。並且發生在這個區域上的GC事件也會被算為major GC。
新生代是用來保存那些第一次被創建的對象，他可以被分為三個空間
- 一個伊甸園空間（Eden ）
- 兩個幸存者空間（Survivor ）
- 絕大多數剛剛被創建的對象會存放在伊甸園空間。
- 在伊甸園空間執行了第一次GC之后，存活的對象被移動到其中一個幸存者空間。
- 此后，在伊甸園空間執行GC之后，存活的對象會被堆積在同一個幸存者空間。
- 當一個幸存者空間飽和，還在存活的對象會被移動到另一個幸存者空間。之后會清空已經飽和的那個幸存者空間。
- 在以上的步驟中重復幾次依然存活的對象，就會被移動到老年代。
jstat 是HotSpot JVM提供的一個監控工具
jstat –gc $<pid$> 1000
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
3008.0 3072.0 0.0 1511.1 343360.0 46383.0 699072.0 283690.2 75392.0 41064.3 2540 18.454 4 1.133 19.588
3008.0 3072.0 0.0 1511.1 343360.0 47530.9 699072.0 283690.2 75392.0 41064.3 2540 18.454 4 1.133 19.588
3008.0 3072.0 0.0 1511.1 343360.0 47793.0 699072.0 283690.2 75392.0 41064.3 2540 18.454 4 1.133 19.588
這些信息很重要，因為它們展示了GC處理到底花費了多少時間。
在這個例子中，YGC 是217而YGCT 是0.928，這樣在簡單的計算數據平均數后，你可以知道每次新生代的GC大概需要4ms（0.004秒），而full GC的平均時間為33ms。
但是，只看數據平均數經常無法分析出真正的GC問題。這是主要是因為GC操作時間嚴重的偏差（換句話說，假如兩次full GC的時間是 67ms，那么其中的一次full GC可能執行了10ms而另一個可能執行了57ms。）為了更好地檢測每次GC處理時間，最好使用 –verbosegc來替代數據平均數。
為什么需要優化GC
或者說的更確切一些，對於基於Java的服務，是否有必要優化GC？應該說，對於所有的基於Java的服務，並不總是需要進行GC優化，但前提是所運行的基於Java的系統，包含了如下參數或行為：
- 已經通過 -Xms 和–Xmx 設置了內存大小
- 包含了 -server 參數
- 系統中沒有超時日志等錯誤日志
換句話說，如果你沒有設定內存的大小，並且系統充斥着大量的超時日志時，你就需要在你的系統中進行GC優化了。
但是，你需要時刻銘記一條：GC優化永遠是最后一項任務。
我為GC優化歸納了兩個目的：
- 一個是將轉移到老年代的對象數量降到最少
- 另一個是減少Full GC的執行時間
將轉移到老年代的對象數量降到最少
按代的GC機制由Oracle JVM提供，不包括可以在JDK7以及更高版本中使用的G1 GC。換句話說，對象被創建在伊甸園空間，而后轉化到幸存者空間，最終剩余的對象被送到老年代。某些比較大的對象會在被創建在伊甸園空間后，直接轉移到老 年代空間。老年代空間上的GC處理會新生代花費更多的時間。因此，減少被移到老年代對象的數據可以顯著地減少Full GC的頻率。減少被移到老年代空間的對象的數量，可能被誤解為將對象留在新生代。但是，這是不可能的。取而代之，你可以調整新生代空間的大小。
減少Full GC執行時間
Full GC的執行時間比Minor GC要長很多。因此，如果Full GC花費了太多的時間（超過1秒），一些連接的部分可能會發生超時錯誤。
- 如果你試圖通過消減老年代空間來減少Full GC的執行時間，可能會導致OutOfMemoryError 或者 Full GC執行的次數會增加。
- 與之相反，如果你試圖通過增加老年代空間來減少Full GC執行次數，執行時間會增加。
因此，你需要將老年代空間設定為一個“合適”的值。
影響GC性能的參數
正如我們在第二篇文章結尾提到的，不要幻想“某個人設定了GC參數后性能得到極大的提高，我們為什么不和他用一樣的參數？”，因為不同的Web服務所創建對象的大小和他們的生命周期都不盡相同。
簡單來說，如果一個任務的執行條件是A，B，C，D和E，同樣的任務執行條件換為A和B，你會覺得哪個更快？從一般人的直覺來看，在A和B條件下執行的任務會更快。
Java GC參數也是相同的道理，設定一些參數不但沒有提高GC執行速度，反而可能導致他更慢。GC優化的最基本原則是將不同的GC參數用於2台或者多台服務器，並進行對比，並將那些被證明提高了性能或者減少了GC執行時間的參數應用於服務器。請謹記這一點。
下面這個表格列出了GC參數中與內存大小相關的，可以影響性能的參數。
表1：GC優化需要考慮的Java參數
| 定義 |
參數 |
描述 |
| 堆內存空間 |
-Xms |
Heap area size when starting JVM 啟動JVM時的堆內存空間。 |
| -Xmx |
Maximum heap area size 堆內存最大限制 |
|
| 新生代空間 |
-XX:NewRatio |
Ratio of New area and Old area 新生代和老年代的占比 |
| -XX:NewSize |
New area size 新生代空間 |
|
| -XX:SurvivorRatio |
Ratio ofEdenarea and Survivor area 伊甸園空間和幸存者空間的占比 |
我在進行GC優化時經常使用-Xms，-Xmx和-XX:NewRatio。-Xms和-Xmx是必須的。你如何設定NewRatio 會對GC性能產生十分顯著的影響。有些人可能會問如何設定Perm區域的大小？你可以通過-XX:PermSize 和-XX:MaxPermSize參數來設定，
當OutOfMemoryError 錯誤發生並且是由於Perm空間不足導致時，另一個可能影響GC性能的參數是GC類型。下表列出了所有可選的GC類型（基於JDK6.0）
在分析監控結果后，決定是否進行GC優化
在檢查GC狀態的過程中，你應該分析監控結果以便決定是否進行GC優化，如果分析結果表明執行GC的時間只有0.1-0.3秒，那你就沒必要浪費時間去進行GC優化。但是，如果GC的執行時間是1-3秒，或者超過10秒，GC將勢在必行。
但是，如果你已經為Java分配了10GB的內存，並且不能再減少內存大小，你將無法再對GC進行優化。在進行GC優化 之前，你必須想清楚你為什么要分配如此大的內存空間。假如當你分1 GB 或 2 GB內存時出現OutOfMemoryError ，你應該執行堆內存轉儲（heap dump），並消除隱患。
注意：
堆內存轉儲是一個用來檢查Java內存中的對象和數據的文件。該文件可以通過執行JDK中的jmap命令來創建。在創建文件的過程中，Java程序會暫停，因此不要再系統執行過程中創建該文件。
如果GC執行時間滿足下面所有的條件，就意味着無需進行GC優化了。
- Minor GC執行的很快（小於50ms）
- Minor GC執行的並不頻繁（大概10秒一次）
- Full GC執行的很快（小於1s）
- Full GC執行的並不頻繁（10分鍾一次）
上面提到的數字並不是絕對的；他們根據服務狀態的不同而有所區別，某些服務可能滿足於Full GC每次0.9秒的速度，但另一些可能不是。因此，針對不同的服務設定不同的值以決定是否進行GC優化。
- 設定內存空間大小
下表展示了內存空間大小，GC執行次數以及GC執行時間三者間的關系。
- 大內存空間
- 減小GC執行次數
- 增加GC執行時間
- 小內存空間
- 減小GC執行時間
- 增加GC執行次數
關於如何設置內存空間的大小，沒有唯一的標准答案。如果服務 器資源足夠，而且Full GC也可能在1秒內完成，設置為10GB當然可行。。但絕大多數服務器並不是這樣，當內存設為10GB時，可能要花費10~30秒來執行Full GC。當然，執行時間會隨對象的大小而改變。
鑒於如此，我們應該如何設定內存空間大小呢？一 般來說，我建議為500MB。不過請注意這不是讓你將WAS的內存參數設置為–Xms500m 和–Xmx500m。根據優化GC之前的狀態，如果 Full GC執行之后內存空間剩余300MB，那么最好將內存設置為1GB（300MB（默認程序占用）+ 500MB（老年代最小空間）+200MB（空閑內存））。也就是說你要為老年代額外設置500MB。因此，如果你有三個執行服務器，內存分別設置為 1GB，1.5GB，2GB，並且檢查結果。
理論上來講，GC執行速度應該遵循1GB> 1.5GB> 2GB,因此1GB執行GC速度最快。但是並不說明1GB空間的Full GC會花費1秒而2GB空間會花費2秒。時間取決於服務器的性能和對象的大小。因此，最佳的方式是建立盡可能多的衡量指標來監控他們。
對於內存空間大小，你應該額外設定NewRatio參數。 NewRatio參數是新生代和老年代空間的比例，即XX:NewRatio=1意味着新生代與老年代之比為1:1。對於1GB來說就是新生代和老年代各 500MB。如果NewRatio為2，意味着新生代老年代之比為1:2，因此該值越大，老年代空間越大，新生代空間越小。
這看似一件不是很重要的事情，但NewRatio參數會顯著地影響整個GC的性能。如果新生代空間很小，會用更多的對象被轉移到老年代空間，這樣導致頻繁的Full GC，增加暫停時間。
你可以簡單的認為NewRatio 為1是最佳的選擇，但是，有時可能設置為2或3更好，我就見過很多這樣的例子。
如何最快的完成GC優化？對比性能測試的結果 應該是最快地方法，為每一台服務器設置不同的參數並監控他們的狀態，強烈建議至少監控1或2天的數據。但是，當你對GC優化是，你要確保每次執行相同的負 載。並且請求的比率，例如URL都應該是一致的。不過，即便對於專業測試人員要想精確的控制負載也是很難的，並要花費大量的時間准備。因此，相對來說比較 方便和容易的方法是調整才參數，之后花費較長的時間收集結果。
示例1
下面這個例子針對 Service S的優化,對於最近被部署的 Service S，Full GC花費了太長的時間。
請看 jstat –gcutil的執行結果。
|
1
2
|
S0 S1 E O P YGC YGCT FGC FGCT GCT
12.16
0.00
5.18
63.78
20.32
54
2.047
5
6.946
8.993
|
最左邊的Perm 空間對於最初的GC優化不是很重要，這一次YGC參數的值更加有用。
Minor GC和Full GC的平均值如下表所示
表3：Service S的Minor GC 和Full GC的平均執行時間
| GC 類型 |
GC 執行次數 |
GC 執行時間 |
平均 |
| Minor GC |
54 |
2.047 |
37 ms |
| Full GC |
5 |
6.946 |
1,389 s |
最重要的是下面兩個數據
- 新生代實際使用空間: 212,992 KB
- 老年代實際使用空間: 1,884,160 KB
因此，總的內存空間為2GB,不算Perm空間的話，新生代與老年代之比為1:9。通過jstat和-verbosegc 日志進行數據收集，並把三台服務器按照如下方式設置。
- NewRatio=2
- NewRatio=3
- NewRatio=4
一天之后，檢查系統的GC日志后發現，在設置了NewRatio參數后很幸運的沒有發生Full GC，
為什么？
- NewRatio=2: 45 ms
- NewRatio=3: 34 ms
- NewRatio=4: 30 ms
我們看到NewRatio=4 是最佳的參數，雖然它的新生代空間最小，但GC時間確最短。設定這個參數之后，系統沒有執行過Full GC。
為了說明這個問題，下面是服務之星一段時間后執行jstat –gcutil的結果
|
1
2
|
S0 S1 E O P YGC YGCT FGC FGCT GCT
8.61
0.00
30.67
24.62
22.38
2424
30.219
0
0.000
30.219
|
你可能會認為因為服務器接受的請求少才導致的GC執行頻率下降。實際上，雖然Full GC沒有執行，但是Minor GC被執行了 2,424次。
示例2
這是一個針對ServiceA的例子，我們通過公司內部的應用性能管理系統（APM）發現JVM暫停了相當長的時間（超過8秒），因此我們進行了GC優化。我們找到了Full GC執行時間過長的原因，並着手解決。
進行GC優化的第一步，就是我們添加了-verbosegc參數，並得到如下結果。
圖1：進行GC優化之前的STW時間
如上圖所示，由HPJMeter自動生成的圖片之一。X坐標表示JVM執行的時間。Y坐標表示每次GC的時間。CMS綠點，表示Full GC結果。Parallel Scavenge藍點，表示Minor GC結果。
之前我曾經說過CMS GC是最快的，但是上面的的結果顯示出於某種原因，它最多花費了15秒。是什么導致這個結果？是否想起我之前提過的，CMS在進行內存清理時，會變慢。與此同時，服務的內存被設定為 –Xms1g和–Xmx4g ，且實際分配了4GB內存。
因此，我將GC類型從CMS改為Parallel GC。並且將內存改為2GB，設定NewRatio 為3。幾小時之后我使用 jstat –gcutil得到如下結果
|
1
2
|
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00
30.48
3.31
26.54
37.01
226
11.131
4
11.758
22.890
|
相對於4GB時的15秒，Full GC變成了平均每次3秒。但是3秒一樣比較慢，因此我設計了如下6種場景。
- Case 1: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=2
- Case 2: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=3
- Case 3: -XX:+UseParallelGC -Xms1g -Xmx1g -XX:NewRatio=3
- Case 4: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=2
- Case 5: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=3
- Case 6: -XX:+UseParallelOldGC -Xms1g -Xmx1g -XX:NewRatio=3
那一個最快呢？結果顯示，內存越小，結果越好。下圖展示了Case6的結果。這是GC的性能最好。最長的響應時間只有1.7秒。平均時間在1秒之內。
圖2：Case6的時間圖表
基於以上結果。我們按照Case6調整了GC參數。但是，這導致了每天晚上都會發生OutOfMemoryError。在這里很難解釋具體的原因。簡單來說，批處理程序導致了內存泄漏。相關的問題已經被解決。
如果對GC日志只分析很短的時間就貿然對所有服務器進行優化是非常危險的。請時刻牢記，你必須同時分析GC日志和應用程序。
我們回顧了兩個關於GC優化的例子，正如我之前提到的，例子中提到的GC參數，可以設置在相同的服務器之上，但前提是他們具有相同的CPU，操作系統，JDK版本以及運行着相同的服務。但是不要直接把我用過的參數用到你的服務至上，它們未必能很好的工作。
切實地調優
如果測試的結果滿足了預期，那么你不需要對程序進行性能調優。如果沒有達到預期結果，你就應該執行調優來解決問題。接下來會通過實例講解方法。
stop-the-world耗時過長
stop-the-world耗時過長可能是由於GC參數不合理或者代碼實現不正確。你可以通過分析工具或堆內存轉儲文件（Heap dump）來定位問題，比如檢查堆內存中對象的類型和數量。如果在其中找到了很多不必要的對象，那么最好去改進代碼。如果沒有發現創建對象的過程中有特別 的問題，那么最好單純地修改GC參數。
為了適當地調整GC參數，你需要獲取一段足夠長時間的GC日志，還必須知道哪些情況會導致長時間的stop-the-world。想了解更多關於如何選擇合適的GC參數，可以閱讀我同事的一篇博文：How to Monitor Java Garbage Collection。
CPU使用率過低
當系統發生阻塞，吞吐量和CPU使用率都會降低。這可能是由於網絡系統或者並發的問題。為了解決這個問題，你可以分析線程轉儲信息（Thread dump）或者使用分析工具。閱讀這篇文章可以獲得更多關於線程轉儲分析的知識：How to Analyze Java Thread Dumps。
你可以使用商業的分析工具對線程鎖進行精確的分析，不過大部分時候，只需使用JVisualVM中的CPU分析器，就能獲得足夠的信息。
CPU使用率過高
如果吞吐量很低但是CPU使用率卻很高，很可能是低效率代碼導致的。這種情況下，你應該使用分析工具定位代碼中性能的瓶頸。可使用的工具有：JVisualVM、Eclipse TPTP或者JProbe。
調優方法
建議你使用如下方法對程序進行調優。
首先，檢查性能調優是否必要。測量性能不是一件簡單的工作，你也不能保證每次都獲得滿意的結果。因此如果程序已經滿足預期性能需求，不必在調優上增加額外的投入了。
問題只出在一個地方，你要做的就是去解決掉它。二八定律（Pareto principle）對性能調優同樣適用。這不是說某個模塊的低性能一定只源於一個問題，而是強調我們應該在調優時把注意力放在影響最大的那個問題上。在處理好了最重要的之后，你才應該去解決剩下其他的。也就是建議一次只對一個問題進行修復。
另外需要考慮到氣球效應（Balloon effect），有得必有失。你可以通過使用緩存來提高響應能力，但是當緩存逐漸增大，執行一次Full GC的時間也會更長。一般而言，如果你希望內存使用率比較低，那么吞吐量和響應能力可能都會惡化。因此，要知道什么對自己程序來說最重要的，而哪些又是次要的。
到此為止，你應該已經了解了如何對Java程序進行性能調優。為了介紹性能測定的具體過程，我不得不省略其中一些細節，不過我認為這些也足夠應對大多數Java Web服務端程序了
2.操作相關
1.如何考慮一個性能需求
1. 通常拿到一個性能需求，需要了解接口模型，整個接口的使用比例和容量，系統結構和技術方案，數據庫緩存和索引分布，設計出合理的測試計划,設計的原則是盡可能真實的模擬線上情況。
2.根據設計出的測試計划，使用一個線程運行測試計划，得出測試結果，對比測試指標
3.以線性增長的方式增加並發數，比較測試結果是否為線性增長
4.測試結果平緩區通常代表着系統容量的最大區域，分析此時的測試結果，如 TPS和響應時間等
5.分析數據庫TPS、QPS等數據，redis命中率,MQ吞吐率，javaGC,程序占用時間等各方面因素提高系統性能
6.通過jstack分析各模塊的資源占用情況。
7.優化后的程序要經過大批量數據測試確保測試程序不會發生錯誤
8.根據測試概要報告，數據庫監控數據等數據整合測試報告
9. 需要關注api層用的是長連接還是短連接，長連接的話需要在jmeter里勾選keep alive
2.如何保證jmeter自身性能
1.使用命令行啟動，減少界面造成的性能問題
2.命令行記錄聚合報告，不要啟動過多的其他監控報告
3.盡可能關閉不必要的日志,包括測試代碼的log,jmeter自身日志。
4.確保測試腳本計時准確，需確認好那些步驟需要計時，那些在准備在計時之外
5.過多的並發使用分布式請求，當本地cpu,mem占用比較大時，修改jmeter.properties，增加遠程remote-server,並啟動（具體操作見jmeter操作手冊）
3.如何分析測試結果
1.根據聚合報告分析90%，95%，和最大等指標，找出程序普遍的響應時間。
2.讓開發人員查詢最大響應時間時的日志，分析程序層面的執行任務情況
3.使用jstack等分析當前程序的資源等待情況，系統資源情況
值得關注的線程狀態有：
死鎖，Deadlock（重點關注）
執行中，Runnable
等待資源，Waiting on condition（重點關注）
等待獲取監視器，Waiting on monitor entry（重點關注）
暫停，Suspended
對象等待中，Object.wait() 或 TIMED_WAITING
阻塞，Blocked（重點關注）
停止，Parked
示例圖
4.分析gc結果，cpu，IO等情況，分析程序是否充分利用了系統資源
5.對比分析各並發數的程序響應情況。