性能調優
性能調優包含多個層次，比如：架構調優、代碼調優、JVM調優、數據庫調優、操作系統調優等。
架構調優和代碼調優是JVM調優的基礎，其中架構調優是對系統影響最大的。
性能調優基本上按照以下步驟進行：明確優化目標、發現性能瓶頸、性能調優、通過監控及數據統計工具獲得數據、確認是否達到目標。
何時進行JVM調優
遇到以下情況，就需要考慮進行JVM調優了：
Heap內存（老年代）持續上漲達到設置的最大內存值；
Full GC 次數頻繁；
GC 停頓時間過長（超過1秒）；
應用出現OutOfMemory 等內存異常；
應用中有使用本地緩存且佔用大量內存空間；
系統吞吐量與響應性能不高或下降。
JVM調優的基本原則
JVM調優是一個手段，但並不一定所有問題都可以通過JVM進行調優解決，因此，在進行JVM調優時，我們要遵循一些原則：
大多數的Java應用不需要進行JVM優化；
大多數導致GC問題的原因是代碼層面的問題導致的（代碼層面）；
上線之前，應先考慮將機器的JVM參數設置到最優；
減少創建對象的數量（代碼層面）；
減少使用全局變量和大對象（代碼層面）；
優先架構調優和代碼調優，JVM優化是不得已的手段（代碼、架構層面）；
分析GC情況優化代碼比優化JVM參數更好（代碼層面）；
通過以上原則，我們發現，其實最有效的優化手段是架構和代碼層面的優化，而JVM優化則是最後不得已的手段，也可以說是對服務器配置的最後一次“壓榨”。
JVM調優目標
調優的最終目的都是爲了令應用程序使用最小的硬件消耗來承載更大的吞吐。jvm調優主要是針對垃圾收集器的收集性能優化，令運行在虛擬機上的應用能夠使用更少的內存以及延遲獲取更大的吞吐量。
延遲：GC低停頓和GC低頻率；
低內存佔用；
高吞吐量;
其中，任何一個屬性性能的提高，幾乎都是以犧牲其他屬性性能的損爲代價的，不可兼得。具體根據在業務中的重要性確定。
JVM調優量化目標
下面展示了一些JVM調優的量化目標參考實例：
Heap 內存使用率 <= 70%;
Old generation內存使用率<= 70%;
avgpause <= 1秒;
Full gc 次數0 或 avg pause interval >= 24小時 ;
注意：不同應用的JVM調優量化目標是不一樣的。
JVM調優的步驟
一般情況下，JVM調優可通過以下步驟進行：
分析GC日誌及dump文件，判斷是否需要優化，確定瓶頸問題點；
確定JVM調優量化目標；
確定JVM調優參數（根據歷史JVM參數來調整）；
依次調優內存、延遲、吞吐量等指標；
對比觀察調優前後的差異；
不斷的分析和調整，直到找到合適的JVM參數配置；
找到最合適的參數，將這些參數應用到所有服務器，並進行後續跟蹤。
以上操作步驟中，某些步驟是需要多次不斷迭代完成的。一般是從滿足程序的內存使用需求開始的，之後是時間延遲的要求，最後纔是吞吐量的要求，要基於這個步驟來不斷優化，每一個步驟都是進行下一步的基礎，不可逆行之。
JVM參數
JVM調優最重要的工具就是JVM參數了。先來了解一下JVM參數相關內容。
-XX 參數被稱爲不穩定參數，此類參數的設置很容易引起JVM 性能上的差異，使JVM存在極大的不穩定性。如果此類參數設置合理將大大提高JVM的性能及穩定性。
不穩定參數語法規則包含以下內容。
布爾類型參數值：
-XX: ’ '表示啓用該選項
-XX:- '-'表示關閉該選項
數字類型參數值：
-XX:=給選項設置一個數字類型值，可跟隨單位，例如：'m’或’M’表示兆字節;'k’或’K’千字節;'g’或’G’千兆字節。32K與32768是相同大小的。
字符串類型參數值：
-XX:=給選項設置一個字符串類型值，通常用於指定一個文件、路徑或一系列命令列表。例如：-XX:HeapDumpPath=./dump.core
JVM參數解析及調優
比如以下參數示例：
-Xmx4g –Xms4g –Xmn1200m –Xss512k -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:PermSize=100m -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15
1
上面爲Java7及以前版本的示例，在Java8中永久代的參數-XX:PermSize和-XX：MaxPermSize已經失效。這在前面章節中已經講到。
參數解析：
-Xmx4g：堆內存最大值爲4GB。
-Xms4g：初始化堆內存大小爲4GB。
-Xmn1200m：設置年輕代大小爲1200MB。增大年輕代後，將會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置爲整個堆的3/8。
-Xss512k：設置每個線程的堆棧大小。JDK5.0以後每個線程堆棧大小爲1MB，以前每個線程堆棧大小爲256K。應根據應用線程所需內存大小進行調整。在相同物理內存下，減小這個值能生成更多的線程。但是操作系統對一個進程內的線程數還是有限制的，不能無限生成，經驗值在3000~5000左右。
-XX:NewRatio=4：設置年輕代（包括Eden和兩個Survivor區）與年老代的比值（除去持久代）。設置爲4，則年輕代與年老代所佔比值爲1：4，年輕代佔整個堆棧的1/5
-XX:SurvivorRatio=8：設置年輕代中Eden區與Survivor區的大小比值。設置爲8，則兩個Survivor區與一個Eden區的比值爲2:8，一個Survivor區佔整個年輕代的1/10
-XX:PermSize=100m：初始化永久代大小爲100MB。
-XX:MaxPermSize=256m：設置持久代大小爲256MB。
-XX:MaxTenuringThreshold=15：設置垃圾最大年齡。如果設置爲0的話，則年輕代對象不經過Survivor區，直接進入年老代。對於年老代比較多的應用，可以提高效率。如果將此值設置爲一個較大值，則年輕代對象會在Survivor區進行多次複製，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概論。
新生代、老生代、永久代的參數，如果不進行指定，虛擬機會自動選擇合適的值，同時也會基於系統的開銷自動調整。
可調優參數：
-Xms：初始化堆內存大小，默認爲物理內存的1/64(小於1GB)。
-Xmx：堆內存最大值。默認(MaxHeapFreeRatio參數可以調整)空餘堆內存大於70%時，JVM會減少堆直到-Xms的最小限制。
-Xmn：新生代大小，包括Eden區與2個Survivor區。
-XX:SurvivorRatio=1：Eden區與一個Survivor區比值爲1:1。
-XX:MaxDirectMemorySize=1G：直接內存。報java.lang.OutOfMemoryError: Direct buffer memory異常可以上調這個值。
-XX: DisableExplicitGC：禁止運行期顯式地調用System.gc()來觸發fulll GC。
注意: Java RMI的定時GC觸發機制可通過配置-Dsun.rmi.dgc.server.gcInterval=86400來控制觸發的時間。
-XX:CMSInitiatingOccupancyFraction=60：老年代內存回收閾值，默認值爲68。
-XX:ConcGCThreads=4：CMS垃圾回收器並行線程線，推薦值爲CPU核心數。
-XX:ParallelGCThreads=8：新生代並行收集器的線程數。
-XX:MaxTenuringThreshold=10：設置垃圾最大年齡。如果設置爲0的話，則年輕代對象不經過Survivor區，直接進入年老代。對於年老代比較多的應用，可以提高效率。如果將此值設置爲一個較大值，則年輕代對象會在Survivor區進行多次複製，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概論。
-XX:CMSFullGCsBeforeCompaction=4：指定進行多少次fullGC之後，進行tenured區 內存空間壓縮。
-XX:CMSMaxAbortablePrecleanTime=500：當abortable-preclean預清理階段執行達到這個時間時就會結束。
在設置的時候，如果關注性能開銷的話，應儘量把永久代的初始值與最大值設置爲同一值，因爲永久代的大小調整需要進行FullGC才能實現。
內存優化示例
當JVM運行穩定之後，觸發了FullGC我們一般會拿到如下信息:
以上gc日誌中，在發生fullGC之時，整個應用的堆佔用以及GC時間。爲了更加精確需多次收集，計算平均值。或者是採用耗時最長的一次FullGC來進行估算。上圖中，老年代空間佔用在93168kb（約93MB），以此定爲老年代空間的活躍數據。則其他堆空間的分配，基於以下規則來進行。
java heap：參數-Xms和-Xmx，建議擴大至3-4倍FullGC後的老年代空間佔用。
永久代：-XX:PermSize和-XX:MaxPermSize，建議擴大至1.2-1.5倍FullGc後的永久帶空間佔用。
新生代：-Xmn，建議擴大至1-1.5倍FullGC之後的老年代空間佔用。
老年代：2-3倍FullGC後的老年代空間佔用。
基於以上規則，則對參數定義如下：
java -Xms373m -Xmx373m -Xmn140m -XX:PermSize=5m -XX:MaxPermSize=5m
1
延遲優化示例
對延遲性優化，首先需要了解延遲性需求及可調優的指標有哪些。
應用程序可接受的平均停滯時間: 此時間與測量的Minor
GC持續時間進行比較。可接受的Minor GC頻率：Minor
GC的頻率與可容忍的值進行比較。
可接受的最大停頓時間:最大停頓時間與最差情況下FullGC的持續時間進行比較。
可接受的最大停頓發生的頻率：基本就是FullGC的頻率。
其中，平均停滯時間和最大停頓時間，對用戶體驗最爲重要。對於上面的指標，相關數據採集包括：MinorGC的持續時間、統計MinorGC的次數、FullGC的最差持續時間、最差情況下，FullGC的頻率。
如上圖，Minor GC的平均持續時間0.069秒，MinorGC的頻率爲0.389秒一次。
新生代空間越大，Minor GC的GC時間越長，頻率越低。如果想減少其持續時長，就需要減少其空間大小。如果想減小其頻率，就需要加大其空間大小。
這裏以減少了新生代空間10%的大小，來減小延遲時間。在此過程中，應該保持老年代和持代的大小不變化。調優後的參數如下變化:
java -Xms359m -Xmx359m -Xmn126m -XX:PermSize=5m -XX:MaxPermSize=5m
1
吞吐量調優
吞吐量調優主要是基於應用程序的吞吐量要求而來的，應用程序應該有一個綜合的吞吐指標，這個指標基於整個應用的需求和測試而衍生出來的。
評估當前吞吐量和目標差距是否巨大，如果在20%左右，可以修改參數，加大內存，再次從頭調試，如果巨大就需要從整個應用層面來考慮，設計以及目標是否一致了，重新評估吞吐目標。
對於垃圾收集器來說，提升吞吐量的性能調優的目標就是儘可能避免或者很少發生FullGC或者Stop-The-World壓縮式垃圾收集（CMS），因爲這兩種方式都會造成應用程序吞吐降低。儘量在MinorGC 階段回收更多的對象，避免對象提升過快到老年代。
調優工具
藉助GCViewer日誌分析工具，可以非常直觀地分析出待調優點。可從以下幾方面來分析：
Memory,分析Totalheap、Tenuredheap、Youngheap內存佔用率及其他指標，理論上內存佔用率越小越好；
Pause，分析Gc pause、Fullgc pause、Total pause三個大項中各指標，理論上GC次數越少越好，GC時長越小越好；
原文鏈接：《JVM性能調優詳解》
本文參考：
（1）https://blog.csdn.net/jisuanjiguoba/article/details/80176223
（2）https://juejin.im/post/59f02f406fb9a0451869f01c
《面試官》系列文章：
《JVM之內存結構詳解》
《面試官，不要再問我“Java GC垃圾回收機制”了》
《面試官，Java8 JVM內存結構變了，永久代到元空間》
《面試官，不要再問我“Java 垃圾收集器”了》
《Java虛擬機類加載器及雙親委派機制》
《Java內存模型(JMM)詳解》
《Java內存模型相關原則詳解》
《JVM性能調優詳解》
————————————————
版權聲明：本文爲CSDN博主「二師兄-公衆號-程序新視界」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/wo541075754/article/details/103007026