此文已由做者趙計剛薪受權網易雲社區發佈。html
歡迎訪問網易雲社區,瞭解更多網易技術產品運營經驗。java
一、JVM的調優主要是內存的調優,主要調兩個方面:web
各個代的大小安全
垃圾收集器選擇服務器
二、各個代的大小併發
經常使用的調節參數eclipse
-Xmxjsp
-Xms微服務
-Xmnspa
-XX:SurvivorRatio
-XX:MaxTenuringThreshold
-XX:PermSize
-XX:MaxPermSize
原則
在實際開發中,前臺不要使用jsp,使用velocity等模板引擎技術
不要引入無關的jar
-XX:SurvivorRatio過大:對象在年輕代的存活時間變長,可能在年輕代就被回收掉而沒必要進入年老代,可是相應的複製的時候survivor區就會被佔用更多的空間。
-XX:SurvivorRatio過大:對象在年輕代的存活時間變短,可能會早早進入年老代而失去在年輕代被回收的機會,可是相應的複製的時候survivor區也就有更多內存了,這樣可能會避免部分大對象直接進入年老代
-XX:SurvivorRatio過大:Eden變大,Survivor變小,minor GC可能減小,可是因爲suvivor減少了,因此若是minor GC存活下來的對象大於suvivor,則會直接進入年老代
-XX:SurvivorRatio太小:Eden變小,Survivor變大,minor GC可能增多,可是因爲suvivor變大了,可以存儲更多存活下來的對象,進入年老代的對象可能會減小
調節時機:minor GC太頻繁
-Xmn太小:minor GC太頻繁;小對象可能也會直接進入年老代,提早致使Full GC
-Xmn過大:年輕代大了,minor GC的時間變長了;年老代變小了,Full GC會頻繁
調節策略:若-Xmx可調大,則調大,且保持-Xmn==-Xmx/4~-Xmx/3;若-Xmx不可調大,在保持-Xmn==-Xmx/4~-Xmx/3的範圍內增大-Xmn,若-Xmn也不可調了,則試着調大-XX:SurvivorRatio來看看狀況
-Xmx==-Xms:防止堆內存頻繁進行調整,調整的時機見《第一章 JVM內存結構》
-Xmn:一般設爲-Xmx/4(這是我在企業中實習時的設置方式,系統運行正常、平穩、速度也快),林昊推薦的是-Xmx/3,因此-Xmn==-Xmx/4~-Xmx/3
-XX:SurvivorRatio:默認8
-XX:MaxTenuringThreshold:默認爲15
-XX:MaxPermSize==-XX:PermSize
三、垃圾收集器選擇
企業中最經常使用的兩個組合:(這裏因爲大部分大型企業用的仍是JDK1.6,因此G1不說)
關於下邊兩組垃圾收集器的詳細原理見:第五章 JVM垃圾收集器(1)
Parallel Scavenge/Parallel Old
注重吞吐量(吞吐量越大,說明CPU利用率越高)
主要用於處理不少的CPU計算任務而用戶交互任務較少的狀況
也用於讓JVM自動調優而咱們袖手旁觀的狀況(-XX:+UseParallelOldGC,-XX:GCTimeRatio,-Xmx,-XX:+UseAdaptiveSizePolicy)
-XX:+UseParallelOldGC:指定使用該組合
ParNew/CMS
注重STW的縮短(該時間越短,用戶體驗越好,並且會減小部分請求的請求超時問題)
-XX:+UseConcMarkSweepGC:指定使用該組合
-XX:CMSInitiatingOccupancyFraction:來指定當年老代空間滿了多少後(百分比)進行垃圾回收
關於上邊兩種組合的說明
通常而言,在企業中,機器的CPU數量都比較多,且CPU的計算能力也不會成爲瓶頸,因此對於CMS的併發標記與併發清除階段,會佔用CPU資源的問題,其實不是大事兒;而對於Parallel的注重吞吐量的問題也就不是什麼大事兒了,畢竟CPU是強大的
因此,ParNew/CMS是首選(在G1不能用的狀況下),Parallel Scavenge/Parallel Old只在想讓JVM自動管理內存的狀況下使用
注意:在實際調優過程當中,可使用jstat、jconsole、visualVM或GC日誌的檢測數據來調,具體的示例見《深刻理解java虛擬機(第二版)》p142對eclipse運行速度的調優。
關於GC日誌的參數含義與每一種垃圾收集器的GC日誌的格式,查看《深刻理解Java虛擬機(第二版)》的P89和《深刻分析java web技術內幕(修訂版)》的P224
免費領取驗證碼、內容安全、短信發送、直播點播體驗包及雲服務器等套餐
更多網易技術、產品、運營經驗分享請點擊。
相關文章:
【推薦】 金融創新業務基於容器雲的微服務化實踐