JVM — 性能調優

概念：

一：堆(Heap)和非堆(Non-heap)內存

　　按照官方的說法：「Java 虛擬機具備一個堆，堆是運行時數據區域，全部類實例和數組的內存均今後處分配。堆是在 Java 虛擬機啓動時建立的。」「在JVM中堆以外的內存稱爲非堆內存(Non-heap memory)」。

 　   能夠看出JVM主要管理兩種類型的內存：堆和非堆。簡單來講堆就是Java代碼可及的內存，是留給開發人員使用的；非堆就是JVM留給本身用的。
 　   因此方法區、JVM內部處理或優化所需的內存(如JIT編譯後的代碼緩存)、每一個類結構(如運行時常數池、字段和方法數據)以及方法和構造方法的代碼都在非堆內存中。 

二：jvm參數的含義

　例：

　　-Xms128m 　　JVM初始分配的堆內存
　　-Xmx512m　　 JVM最大容許分配的堆內存，按需分配
　　-XX:PermSize=64M 　　JVM初始分配的非堆內存
　　-XX:MaxPermSize=128M 　　JVM最大容許分配的非堆內存，按需分配 

　　Xmx（memory max）表明程序最大能夠從操做系統中獲取的內存數量，Xms（memory start ）表明程序啓動的時候從操做系統中獲取的內存數量。

　　好比java -cp . -Xms80m -Xmx256m 說明這個程序啓動的時候使用80m的內存，最多能夠從操做系統中獲取256m的內存。

三：堆內存分配和非堆內存分配

　　堆內存分配：

　　   JVM初始分配的堆內存由-Xms指定，默認是物理內存的1/64；JVM最大分配的堆內存由-Xmx指定，默認是物理內存的1/4。默認空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制；
 空餘堆內存大於70%時，JVM會減小堆直到-Xms的最小限制。所以服務器通常設置-Xms、-Xmx 相等以免在每次GC 後調整堆的大小。
 　　說明：若是-Xmx 不指定或者指定偏小，應用可能會致使java.lang.OutOfMemory錯誤，此錯誤來自JVM，不是Throwable的，沒法用try...catch捕捉。

　　非堆內存分配：

　　   JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。（還有一說：MaxPermSize缺省值和-server -client選項相關，-server選項下默認MaxPermSize爲64m，-client選項下默認MaxPermSize爲32m。這個我沒有實驗。）
 　　上面錯誤信息中的PermGen space的全稱是Permanent Generation space，是指內存的永久保存區域。尚未弄明白PermGen space是屬於非堆內存，仍是就是非堆內存，但至少是屬於了。
　　 XX:MaxPermSize設置太小會致使java.lang.OutOfMemoryError: PermGen space 就是內存益出。 
　　 說說爲何會內存益出： 
　　　　（1）這一部份內存用於存放Class和Meta的信息，Class在被 Load的時候被放入PermGen space區域，它和存放Instance的Heap區域不一樣。 
　　　　（2）GC(Garbage Collection)不會在主程序運行期對PermGen space進行清理，因此若是你的APP會LOAD不少CLASS 的話,就極可能出現PermGen space錯誤。
  　　　　這種錯誤常見在web服務器對JSP進行pre compile的時候。 

---

 

（1）JVM內存模型及垃圾收集算法

　　1.根據Java虛擬機規範，JVM將內存劃分爲：　　

• • New（年輕代）
  • Tenured（年老代）
  • 永久代（Perm）

　　其中New和Tenured屬於堆內存，堆內存會從JVM啓動參數（-Xmx:3G）指定的內存中分配，Perm不屬於堆內存，有虛擬機直接分配，但能夠經過-XX:PermSize -XX:MaxPermSize 等參數調整其大小。

• 年輕代（New）：年輕代用來存放JVM剛分配的Java對象
• 年老代（Tenured)：年輕代中通過垃圾回收沒有回收掉的對象將被Copy到年老代
• 永久代（Perm）：永久代存放Class、Method元信息，其大小跟項目的規模、類、方法的量有關，通常設置爲128M就足夠，設置原則是預留30%的空間。　　

　　New又分爲幾個部分：

• Eden：Eden用來存放JVM剛分配的對象
• Survivor1
• Survivro2：兩個Survivor空間同樣大，當Eden中的對象通過垃圾回收沒有被回收掉時，會在兩個Survivor之間來回Copy，當知足某個條件，好比Copy次數，就會被Copy到Tenured。顯然，Survivor只是增長了對象在年輕代中的逗留時間，增長了被垃圾回收的可能性。　

 　　2.垃圾回收算法

  　　垃圾回收算法能夠分爲三類，都基於標記-清除（複製）算法：

• • Serial算法（單線程）
  • 並行算法
  • 併發算法

  　　JVM會根據機器的硬件配置對每一個內存代選擇適合的回收算法，好比，若是機器多於1個核，會對年輕代選擇並行算法，關於選擇細節請參考JVM調優文檔。

  　　稍微解釋下的是，並行算法是用多線程進行垃圾回收，回收期間會暫停程序的執行，而併發算法，也是多線程回收，但期間不中止應用執行。因此，併發算法適用於交互性高的一些程序。通過觀察，併發算法會減小年輕代的大小，其實就是使用了一個大的年老代，這反過來跟並行算法相比吞吐量相對較低。

  　　還有一個問題是，垃圾回收動做什麼時候執行？

• 當年輕代內存滿時，會引起一次普通GC，該GC僅回收年輕代。須要強調的時，年輕代盡是指Eden代滿，Survivor滿不會引起GC
• 當年老代滿時會引起Full GC，Full GC將會同時回收年輕代、年老代
• 當永久代滿時也會引起Full GC，會致使Class、Method元信息的卸載

  另外一個問題是，什麼時候會拋出OutOfMemoryException，並非內存被耗空的時候才拋出

• JVM98%的時間都花費在內存回收
• 每次回收的內存小於2%

  知足這兩個條件將觸發OutOfMemoryException，這將會留給系統一個微小的間隙以作一些Down以前的操做，好比手動打印Heap Dump。

---

 （2）內存泄漏及解決方法　　

1.系統崩潰前的一些現象：

• 每次垃圾回收的時間愈來愈長，由以前的10ms延長到50ms左右，FullGC的時間也有以前的0.5s延長到四、5s
• FullGC的次數愈來愈多，最頻繁時隔不到1分鐘就進行一次FullGC
• 年老代的內存愈來愈大而且每次FullGC後年老代沒有內存被釋放

 　　以後系統會沒法響應新的請求，逐漸到達OutOfMemoryError的臨界值。

 2.生成堆的dump文件

 　　經過JMX的MBean生成當前的Heap信息，大小爲一個3G（整個堆的大小）的hprof文件，若是沒有啓動JMX能夠經過Java的jmap命令來生成該文件。

 3.分析dump文件

 　　下面要考慮的是如何打開這個3G的堆信息文件，顯然通常的Window系統沒有這麼大的內存，必須藉助高配置的Linux。固然咱們能夠藉助X-Window把Linux上的圖形導入到Window。咱們考慮用下面幾種工具打開該文件：

1. Visual VM
2. IBM HeapAnalyzer
3. JDK 自帶的Hprof工具

 　　使 用這些工具時爲了確保加載速度，建議設置最大內存爲6G。使用後發現，這些工具都沒法直觀地觀察到內存泄漏，Visual VM雖能觀察到對象大小，但看不到調用堆棧；HeapAnalyzer雖然能看到調用堆棧，卻沒法正確打開一個3G的文件。所以，咱們又選用了 Eclipse專門的靜態內存分析工具：Mat。

 4.分析內存泄漏

　　 經過Mat咱們能清楚地看到，哪些對象被懷疑爲內存泄漏，哪些對象佔的空間最大及對象的調用關係。針對本案，在ThreadLocal中有不少的JbpmContext實例，通過調查是JBPM的Context沒有關閉所致。

 另，經過Mat或JMX咱們還能夠分析線程狀態，能夠觀察到線程被阻塞在哪一個對象上，從而判斷系統的瓶頸。

5.迴歸問題

   Q：爲何崩潰前垃圾回收的時間愈來愈長？

   A:根據內存模型和垃圾回收算法，垃圾回收分兩部分：內存標記、清除（複製），標記部分只要內存大小固定時間是不變的，變的是複製部分，由於每次垃圾回收都有一些回收不掉的內存，因此增長了複製量，致使時間延長。因此，垃圾回收的時間也能夠做爲判斷內存泄漏的依據

   Q：爲何Full GC的次數愈來愈多？

   A：所以內存的積累，逐漸耗盡了年老代的內存，致使新對象分配沒有更多的空間，從而致使頻繁的垃圾回收

   Q:爲何年老代佔用的內存愈來愈大？

   A:由於年輕代的內存沒法被回收，愈來愈多地被Copy到年老代

---

 三：性能調優

　　從四個方便入手：　　

• • 線程池：解決用戶響應時間長的問題
  • 鏈接池
  • JVM啓動參數：調整各代的內存比例和垃圾回收算法，提升吞吐量
  • 程序算法：改進程序邏輯算法提升性能

　　下面只介紹JVM的啓動參數優化

　　 在JVM啓動參數中，能夠設置跟內存、垃圾回收相關的一些參數設置，默認狀況不作任何設置JVM會工做的很好，但對一些配置很好的Server和具體的應用必須仔細調優才能得到最佳性能。經過設置咱們但願達到一些目標：

• GC的時間足夠的小
• GC的次數足夠的少
• 發生Full GC的週期足夠的長

　　前兩個目前是相悖的，要想GC時間小必需要一個更小的堆，要保證GC次數足夠少，必須保證一個更大的堆，咱們只能取其平衡。

   （1）針對JVM堆的設置，通常能夠經過-Xms -Xmx限定其最小、最大值，爲了防止垃圾收集器在最小、最大之間收縮堆而產生額外的時間，咱們一般把最大、最小設置爲相同的值
   （2）年輕代和年老代將根據默認的比例（1：2）分配堆內存， 能夠經過調整兩者之間的比率NewRadio來調整兩者之間的大小，也能夠針對回收代，好比年輕代，經過 -XX:newSize -XX:MaxNewSize來設置其絕對大小。一樣，爲了防止年輕代的堆收縮，咱們一般會把-XX:newSize -XX:MaxNewSize設置爲一樣大小

   （3）年輕代和年老代設置多大才算合理？這個我問題毫無疑問是沒有答案的，不然也就不會有調優。咱們觀察一下兩者大小變化有哪些影響

• 更大的年輕代必然致使更小的年老代，大的年輕代會延長普通GC的週期，但會增長每次GC的時間；小的年老代會致使更頻繁的Full GC
• 更小的年輕代必然致使更大年老代，小的年輕代會致使普通GC很頻繁，但每次的GC時間會更短；大的年老代會減小Full GC的頻率
• 如何選擇應該依賴應用程序對象生命週期的分佈狀況： 若是應用存在大量的臨時對象，應該選擇更大的年輕代；若是存在相對較多的持久對象，年老代應該適當增大。但不少應用都沒有這樣明顯的特性，在抉擇時應該根 據如下兩點：（A）本着Full GC儘可能少的原則，讓年老代儘可能緩存經常使用對象，JVM的默認比例1：2也是這個道理 （B）經過觀察應用一段時間，看其餘在峯值時年老代會佔多少內存，在不影響Full GC的前提下，根據實際狀況加大年輕代，好比能夠把比例控制在1：1。但應該給年老代至少預留1/3的增加空間

  （4）在配置較好的機器上（好比多核、大內存），能夠爲年老代選擇並行收集算法： -XX:+UseParallelOldGC ，默認爲Serial收集

  （5）線程堆棧的設置：每一個線程默認會開啓1M的堆棧，用於存放棧幀、調用參數、局部變量等，對大多數應用而言這個默認值太了，通常256K就足用。理論上，在內存不變的狀況下，減小每一個線程的堆棧，能夠產生更多的線程，但這實際上還受限於操做系統。

  （4）能夠經過下面的參數打Heap Dump信息

• -XX:HeapDumpPath
• -XX:+PrintGCDetails
• -XX:+PrintGCTimeStamps
• -Xloggc:/usr/aaa/dump/heap_trace.txt

    經過下面參數能夠控制OutOfMemoryError時打印堆的信息

• -XX:+HeapDumpOnOutOfMemoryError

 　請看一下一個時間的Java參數配置：（服務器：Linux 64Bit，8Core×16G）

 

 JAVA_OPTS="$JAVA_OPTS -server -Xms3G -Xmx3G -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/aaa/dump -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/usr/aaa/dump/heap_trace.txt -XX:NewSize=1G -XX:MaxNewSize=1G"

　　通過觀察該配置很是穩定，每次普通GC的時間在10ms左右，Full GC基本不發生，或隔很長很長的時間才發生一次

　　經過分析dump文件能夠發現，每一個1小時都會發生一次Full GC，通過多方求證，只要在JVM中開啓了JMX服務，JMX將會1小時執行一次Full GC以清除引用。

---

 

調優方法：

　　一切都是爲了這一步，調優，在調優以前，咱們須要記住下面的原則：

　　　　一、多數的Java應用不須要在服務器上進行GC優化；

　　　　二、多數致使GC問題的Java應用，都不是由於咱們參數設置錯誤，而是代碼問題；

　　　　三、在應用上線以前，先考慮將機器的JVM參數設置到最優（最適合）；

　　　　四、減小建立對象的數量；

　　　　五、減小使用全局變量和大對象；

　　　　六、GC優化是到最後不得已才採用的手段；

　　　　七、在實際使用中，分析GC狀況優化代碼比優化GC參數要多得多；

　　GC優化的目的有兩個：　　　

　　　　一、將轉移到老年代的對象數量下降到最小；

　　　　二、減小full GC的執行時間；　　

　　爲了達到上面的目的，通常地，你須要作的事情有：

　　　　一、減小使用全局變量和大對象；

　　　　二、調整新生代的大小到最合適；

　　　　三、設置老年代的大小爲最合適；

　　　　四、選擇合適的GC收集器；

調優實例：

　　實例1：

　　發現部分開發測試機器出現異常：java.lang.OutOfMemoryError: GC overhead limit exceeded，這個異常表明：GC爲了釋放很小的空間卻耗費了太多的時間，其緣由通常有兩個：1，堆過小，2，有死循環或大對象；

　　首先排除了第2個緣由，由於這個應用同時是在線上運行的，若是有問題，早就掛了。因此懷疑是這臺機器中堆設置過小；

　　使用ps -ef |grep "java"查看，發現：

　　　

　　該應用的堆區設置只有768m，而機器內存有2g，機器上只跑這一個java應用，沒有其餘須要佔用內存的地方。另外，這個應用比較大，須要佔用的內存也比較多；

　　經過上面的狀況判斷，只須要改變堆中各區域的大小設置便可，因而改爲下面的狀況：

　　

　　跟蹤運行狀況發現，相關異常沒有再出現

　　實例2：

　　一個服務系統，常常出現卡頓，分析緣由，發現Full GC時間太長：

　　jstat -gcutil:

　　　　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 　　

　　分析上面的數據，發現Young GC執行了54次，耗時2.047秒，每次Young GC耗時37ms，在正常範圍，而Full GC執行了5次，耗時6.946秒，每次平均1.389s，數據顯示出來的問題是：Full GC耗時較長，分析該系統的是指發現，NewRatio=9，也就是說，新生代和老生代大小之比爲1:9，這就是問題的緣由：

　　1，新生代過小，致使對象提早進入老年代，觸發老年代發生Full GC；

　　2，老年代較大，進行Full GC時耗時較大；

　　優化的方法是調整NewRatio的值，調整到4，發現Full GC沒有再發生，只有Young GC在執行。這就是把對象控制在新生代就清理掉，沒有進入老年代（這種作法對一些應用是頗有用的，但並非對全部應用都要這麼作）

　　實例3：

　　一 應用在性能測試過程當中，發現內存佔用率很高，Full GC頻繁，使用sudo -u admin -H  jmap -dump:format=b,file=文件名.hprof pid 來dump內存，生成dump文件，並使用Eclipse下的mat差距進行分析，發現：

　　

　　從圖中能夠看出，這個線程存在問題，隊列LinkedBlockingQueue所引用的大量對象並未釋放，致使整個線程佔用內存高達378m，此時通知開發人員進行代碼優化，將相關對象釋放掉便可。

 

 出處資料：https://www.cnblogs.com/downey/p/5352593.html