关键系统的JVM参数推荐
前言2， -XX:+PrintFlagsFinal打印參數值
當你在網上興沖沖找到一個可優化的參數時，先打印看看，它可能已經默認打開了，再找到一個，還是默認打開了...
JDK7與JDK8，甚至JDK7中的不同小版本，有些參數值都不一樣，所以不要輕信網上任何文章，一切以生產環境同版本的JDK打出來的為準。
經常以類似下面的語句去查看參數，偷懶不起應用，用-version代替。有些參數設置后會影響其他參數，所以也得帶上。
java ?-XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -version| grep GCThreads
對于不同版本里的默認值，建議是順勢而為，JDK在那個版本默認打開不打開總有它的理由。安全第一，沒有很好的因由，不要隨便因為網上某篇文章的推薦(包括你現在在讀的這篇)就去設置。
?
1. 性能篇
1.1 建議的性能參數
1. 取消偏向鎖： -XX:-UseBiasedLocking
JDK1.6開始默認打開的偏向鎖，會嘗試把鎖賦給第一個訪問它的線程，取消同步塊上的synchronized原語。如果始終只有一條線程在訪問它，就成功略過同步操作以獲得性能提升。
但一旦有第二條線程訪問這把鎖，JVM就要撤銷偏向鎖恢復之前的狀態，如果打開安全點日志，可以看到不少RevokeBiasd的紀錄，像GC一樣Stop The World的干活，雖然只是很短的停頓，但對于多線程并發的應用，取消掉它反而有性能的提升，所以Cassandra就取消了它。?
2. 加大Integer Cache： -XX:AutoBoxCacheMax=20000
Integer i=3;這語句有著 int自動裝箱成Integer的過程，JDK默認只緩存 -128 ~ +127的Integer 和 Long，超出范圍的數字就要即時構建新的Integer對象。設為20000后，我們應用的QPS有足足4%的提升。為什么是2萬呢，因為-XX:+AggressiveOpts里也是這個值。 詳見《Java Integer(-128~127)值的==和equals比較產生的思考》。?
3. 啟動時訪問并置零內存頁面： -XX:+AlwaysPreTouch
啟動時就把參數里說好了的內存全部舔一遍，可能令得啟動時慢上一點，但后面訪問時會更流暢，比如頁面會連續分配，比如不會在晉升老生代時才去訪問頁面使得GC停頓時間加長。ElasticSearch和Cassandra都打開了它。?
4. SecureRandom生成加速： -Djava.security.egd=file:/dev/./urandom
此江湖偏方原因是Tomcat的SecureRandom顯式使用SHA1PRNG算法時，初始因子默認從/dev/random讀取會存在堵塞。額外效果是SecureRandom的默認算法也變成更合適的SHA1了。詳見 《SecureRandom的江湖偏方與真實效果》?
1.2 可選的性能參數
1. -XX:+PerfDisableSharedMem
Cassandra家的一個參數，一直沒留意，直到發生高IO時的JVM停頓。原來JVM經常會默默的在/tmp/hperf?目錄寫上一點statistics數據，如果剛好遇到PageCache刷盤，把文件阻塞了，就不能結束這個Stop the World的安全點了。
禁止JVM寫statistics數據的代價，是jps和jstat 用不了，只能用JMX，而JMX取新老生代的使用百分比還真沒jstat方便，VJTools的vjmxcli彌補了這一點。詳見《The Four Month Bug: JVM statistics cause garbage collection pauses》
2. -XX:-UseCounterDecay
禁止JIT調用計數器衰減。默認情況下，每次GC時會對調用計數器進行砍半的操作，導致有些方法一直溫熱，永遠都達不到觸發C2編譯的1萬次的閥值。
3. -XX:-TieredCompilation
多層編譯是JDK8后默認打開的比較驕傲的功能，先以C1靜態編譯，采樣足夠后C2編譯。
但我們實測，性能最終略降2%，可能是因為有些方法C1編譯后C2不再編譯了。應用啟動時的偶發服務超時也多了，可能是忙于編譯。所以我們將它禁止了，但記得打開前面的-XX:-UseCounterDecay，避免有些溫熱的方法永遠都要解釋執行。
?
1.3 不建議的性能參數
1. -XX:+AggressiveOpts
一些還沒默認打開的優化參數集合,?-XX:AutoBoxCacheMax是其中的一項。但如前所述，關鍵系統里不建議打開。雖然通過-XX:+AggressiveOpts?與?-XX:-AggressiveOpts?的對比，目前才改變了三個參數，但為免以后某個版本的JDK里默默改變更多激進的配置，還是不要打開了。
2. JIT Compile相關的參數，函數調用多少次之后開始編譯的閥值，內聯函數大小的閥值等等，不要亂改。
3.?-server，在64位多核的linux中，你想設成-client都不行的，所以寫了也是白寫。?
2. 內存與GC篇
2.1 GC策略
為了穩健，還是8G以下的堆還是CMS好了，G1現在雖然是默認了，但其實在小堆里的表現也沒有比CMS好，還是JDK11的ZGC引人期待。
1.CMS基本寫法
-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly
因為我們的監控系統會通過JMX監控內存達到90%的狀況，所以設置讓它75%就開始跑了，早點開始也能減少Full GC等意外情況(概念重申，這種主動的CMS GC，和JVM的老生代、永久代、堆外內存完全不能分配內存了而強制Full GC是不同的概念)。為了讓這個設置生效，還要設置UseCMSInitiatingOccupancyOnly，否則75％只被用來做開始的參考值，后來還是JVM自己算。?
2. -XX:MaxTenuringThreshold=2
這是改動效果最明顯的一個參數了。對象在Survivor區最多熬過多少次Young GC后晉升到年老代，JDK8里CMS 默認是6，其他如G1是15。
Young GC是最大的應用停頓來源，而YGC后存活對象的多少又直接影響停頓的時間，所以如果清楚Young GC的執行頻率和應用里大部分臨時對象的最長生命周期，可以把它設的更短一點，讓其實不是臨時對象的新生代對象趕緊晉升到年老代，別呆著。
用-XX:+PrintTenuringDistribution觀察下，如果后面幾代的大小總是差不多，證明過了某個年齡后的對象總能晉升到老生代，就可以把晉升閾值設小，比如JMeter里2就足夠了。?
3. -XX:+ExplicitGCInvokesConcurrent 但不要加-XX:+DisableExplicitGC
讓full gc時使用CMS算法，不是全程停頓，必選。
但像R大說的，System GC是保護機制（如堆外內存滿時清理它的堆內引用對象），禁了system.gc() 未必是好事，只要沒用什么特別爛的類庫，真有人調了總有調的原因，所以不應該加這個爛大街的參數。?
4.?-XX:+ParallelRefProcEnabled 和?-XX:+CMSParallelInitialMarkEnabled
并行的處理Reference對象，如WeakReference，默認為false，除非在GC log里出現Reference處理時間較長的日志，否則效果不會很明顯，但我們總是要JVM盡量的并行，所以設了也就設了。同理還有-XX:+CMSParallelInitialMarkEnabled，JDK8已默認開啟，但小版本比較低的JDK7甚至不支持。?
5. ParGCCardsPerStrideChunk
Linkined的黑科技， 2016版不建議打開，后來發現有些場景的確能減少YGC時間，詳見《難道他們說的都是真的》，簡單說就是影響YGC時掃描老生代的時間，默認值256太小了，但32K也未必對，需要自己試驗。
-XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=1024?
2.2 可選的GC參數
1. 并發收集線程數
ParallelGCThreads＝8+( Processor - 8 ) ( 5/8 )；ConcGCThreads = (ParallelGCThreads + 3)/4
比如雙CPU，六核，超線程就是24個處理器，小于8個處理器時ParallelGCThreads按處理器數量，大于時按上述公式YGC線程數＝18， CMS GC線程數＝5。
CMS GC線程數的公式太怪，也有人提議簡單改為YGC線程數的1/2。
一些不在乎停頓時間的后臺輔助程序，比如日志收集的logstash，建議把它減少到2，避免在GC時突然占用太多CPU核，影響主應用。
而另一些并不獨占服務器的應用，比如旁邊跑著一堆sidecar的，也建議減少YGC線程數。
一個真實的案例，24核的服務器，默認18條YGC線程，因為旁邊有個繁忙的Service Mesh Proxy在跑著，這18條線程并不能100%的搶到CPU，出現了不合理的慢GC，把線程數降低到12條反而更快了。 所以那些貪心的把YGC線程數＝CPU 核數的，通常弄巧成拙。?
2. -XX:-CMSClassUnloadingEnabled
在CMS中清理永久代中的過期的Class而不等到Full GC，JDK7默認關閉而JDK8打開?？醋约呵闆r，比如有沒有運行動態語言腳本如Groovy產生大量的臨時類。它有時會大大增加CMS GC的暫停時間。所以如果新類加載并不頻繁，這個參數還是顯式關閉的好。?
3. -XX:+CMSScavengeBeforeRemark
默認為關閉，在CMS remark前，先執行一次minor GC將新生代清掉，這樣從老生代的對象引用到的新生代對象的個數就少了，停止全世界的CMS remark階段就短一些。但如果打開了，會讓一次YGC緊接著一次CMS GC，使得停頓的總時間加長了。
又一個真實案例，CMS GC的時間和新生代的使用量成比例，新生代較小時很快完成，新生代快滿時CMS GC的停頓時間超過2秒，這時候就還是打開了劃算。
?
2.3 不建議的GC參數
1. -XX:+UseParNewGC
用了CMS，新生代收集默認就是它，不用自己設。
?2. -XX:CMSFullGCsBeforeCompaction默認為0，即每次Full GC都對老生代進行碎片整理壓縮。Full GC 不同于 老生代75%時觸發的CMS GC，只在老生代達到100%，堆外內存滿，老生代碎片過大無法分配空間給新晉升的大對象這些特殊情況里發生，所以設為每次都進行碎片整理是合適的，詳見此貼里R大的解釋。
?3.-XX:+GCLockerInvokesConcurrent
我們犯過的錯，不是所有Concurrent字樣的參數都是好參數，加上之后，原本遇上JNI GCLocker只需要補償YGC就夠的，變成要執行YGC ＋ CMS GC了。
?
2.4 內存大小的設置
其實JVM除了顯式設置的-Xmx堆內存，還有一堆其他占內存的地方(堆外內存，線程棧，永久代，二進制代碼cache)，在容量規劃的時候要留意。
關鍵業務系統的服務器上內存一般都是夠的，所以盡管設得寬松點。
1. -Xmx, -Xms,堆內存大小，2～4G均可。
?2. -Xmn or -XX:NewSize or -XX:NewRatio
JDK默認新生代占堆大小的1/3， 個人喜歡把對半分， 因為增大新生代能減少GC的頻率，如果老生代里沒多少長期對象的話，占2/3通常太多了?？梢杂?Xmn 直接賦值(等于-XX:NewSize and -XX:MaxNewSize同值的縮寫)，或把NewRatio設為1來對半分。
?3. -XX: PermSize=128m -XX:MaxPermSize=512m （JDK7）-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m（JDK8）
現在的應用有Hibernate/Spring這些鬧騰的家伙AOP之后類都比較多，可以一開始就把初始值從64M設到128M（否則第一次自動擴張會造成大約3秒的JVM停頓），并設一個更大的Max值以求保險。
JDK8的永生代幾乎可用完機器的所有內存，同樣設一個128M的初始值，512M的最大值保護一下。
?
2.5 其他內存大小的設置
1. -Xss
在堆之外，線程占用棧內存，默認每條線程為1M（以前是256K）。存放方法調用出參入參的棧，局部變量，標量替換后掉局部變量等，有人喜歡把它設回256k如Cassandra，節約內存并開更多線程，有人則會在遇到錯誤后把它再設大點，特別是有很深的JSON解析之類的遞歸調用時。?
2. -XX:SurvivorRatio
新生代中每個存活區的大小，默認為8，即1/10的新生代 1/(SurvivorRatio+2)，有人喜歡設小點省點給新生代，但要避免太小使得存活區放不下臨時對象而被迫晉升到老生代，還是從GC日志里看實際情況了。?
3. -XX:MaxDirectMemorySize
堆外內存的最大值，默認為Heap區總內存減去一個Survivor區的大小，詳見《Netty之堆外內存掃盲篇》，如果肯定用不了這么多，也可以把它主動設小，來獲得一個比較清晰內存占用預估值，特別是在容器里。?
4. -XX:ReservedCodeCacheSize
JIT編譯后二進制代碼的存放區，滿了之后就不再編譯，對性能影響很大。 JDK7默認不開多層編譯48M，開了96M，而JDK8默認開多層編譯240M。可以在JMX里看看CodeCache的占用情況，也可以用VJTools里的vjtop來看，JDK7下默認的48M可以設大點，不摳這么點。
?
3. 監控篇
JVM輸出的各種日志，如果未指定路徑，通常會生成到運行應用的相同目錄，為了避免有時候在不同的地方執行啟動腳本，一般將日志路徑集中設到一個固定的地方。
3.1 監控建議配置
1. -XX:+PrintCommandLineFlags
運維有時會對啟動參數做一些臨時的更改，將每次啟動的參數輸出到stdout，將來有據可查。打印出來的是命令行里設置了的參數以及因為這些參數隱式影響的參數，比如開了CMS后，-XX:+UseParNewGC也被自動打開。?
2. -XX:-OmitStackTraceInFastThrow
為異常設置StackTrace是個昂貴的操作，所以當應用在相同地方拋出相同的異常N次(兩萬?)之后，JVM會對某些特定異常如NPE，數組越界等進行優化，不再帶上異常棧。此時，你可能會看到日志里一條條Nul Point Exception，而之前輸出完整棧的日志早被滾動到不知哪里去了，也就完全不知道這NPE發生在什么地方，欲哭無淚。 所以，將它禁止吧，ElasticSearch也這樣干。
?
3.2 Crash文件
1. -XX:ErrorFile
JVM crash時，hotspot 會生成一個error文件，提供JVM狀態信息的細節。如前所述，將其輸出到固定目錄，避免到時會到處找這文件。文件名中的%p會被自動替換為應用的PID
-XX:ErrorFile=${LOGDIR}/hs_err_%p.log
?2. coredump
當然，更好的做法是生成coredump，從CoreDump能夠轉出Heap Dump 和 Thread Dump 還有crash的地方，非常實用。
在啟動腳本里加上?ulimit -c unlimited或其他的設置方式，如果有root權限，設一下輸出目錄更好
echo "/{MYLOGDIR}/coredump.%p" > /proc/sys/kernel/core_pattern
什么？你不知道coredump有什么用？看來你是沒遇過JVM Segment Fault的幸福人。?
3. -XX:+HeapDumpOnOutOfMemoryError(可選)
在Out Of Memory，JVM快死掉的時候，輸出Heap Dump到指定文件。不然開發很多時候還真不知道怎么重現錯誤。
路徑只指向目錄，JVM會保持文件名的唯一性，叫java_pid${pid}.hprof。因為如果指向文件，而文件已存在，反而不能寫入。
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${LOGDIR}/
但在容器環境下，輸出4G的HeapDump，在普通硬盤上會造成20秒以上的硬盤IO跑滿，也是個十足的惡鄰，影響了同一宿主機上所有其他的容器。
?
3.3 GC日志
JDK9完全不一樣了，這里還是寫JDK7/8的配置。
1.基本配置
-Xloggc:/dev/shm/gc-myapp.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails
有人擔心寫GC日志會影響性能，但測試下來實在沒什么影響，GC問題是Java里最常見的問題，沒日志怎么行。
后來又發現如果遇上高IO的情況，GC時操作系統正在flush pageCache 到磁盤的話，也可能導致GC log文件被鎖住，從而讓GC結束不了。所以把它指向了/dev/shm 這種內存中文件系統，避免這種停頓，詳見《Eliminating Large JVM GC Pauses Caused by Background IO Traffic》
用PrintGCDateStamps而不是PrintGCTimeStamps，打印可讀的日期而不是時間戳。
?2. -XX:+PrintGCApplicationStoppedTime
這是個非常非常重要的參數，它的名字沒起好，它除了打印清晰的完整的GC停頓時間外，還可以打印其他的JVM停頓時間，比如取消偏向鎖，class 被agent redefine，code deoptimization等等，有助于發現一些原來沒想到的問題，建議也加上。如果真的發現了一些不知是什么的停頓，需要打印安全點日志找原因。
?3. -XX:+PrintGCCause
打印產生GC的原因，比如AllocationFailure什么的，在JDK8已默認打開，JDK7要顯式打開一下。
?4. -XX:+PrintPromotionFailure
打開了就知道是多大的新生代對象晉升到老生代失敗從而引發Full GC時的。
?5. GC日志滾動與備份
GC日志默認會在重啟后清空，有人擔心長期運行的應用會把文件弄得很大，所以"-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=1M"的參數可以讓日志滾動起來。但真用起來重啟后的文件名太混亂太讓人頭痛，GC日志再大也達不到哪里去，所以我們沒有加滾動，并且自行在啟動腳本里對舊日志做備份。
?
3.4 安全點日志
如果GC日志里有非GC的JVM停頓時間，你得打出安全點日志來知道詳情，詳見《 JVM的Stop The World，安全點，黑暗的地底世界》
-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/dev/shm/vm-myapp.log
3.5 JMX
-Dcom.sun.management.jmxremote.port=7001 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=127.0.0.1
以上設置，只讓本地的Zabbix之類監控軟件通過JMX監控JVM，不允許遠程訪問。
如果應用忘記了加上述參數，又不想改參數重啟服務，可以用VJTools的vjmxcli來救急，它能通過PID直接連入目標JVM打開JMX。
?
4. 小結
謝謝大家看到這里，上文的所有內容，其實都在VJTools的?jvm-options.sh 里面了。如果覺得能省了大家的時間，麻煩給項目點個Star。
轉載于:https://blog.51cto.com/jack88/2369035
新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！總結
以上是生活随笔為你收集整理的关键系统的JVM参数推荐的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： rhel6 上udev的绑定
- 下一篇： SQL server中的SELECT查询