JVM 你不可不知的參數

有的同學雖然寫了一段時間 Java 了,但是對于 JVM 卻不太關注。有的同學說,參數都是團隊規定好的,部署的時候也不用我動手,關注它有什么用,而且,JVM 這東西,聽上去就感覺很神秘很高深的樣子,還是算了吧。

沒錯,部署的時候可能用不到你親自動手,但是出現問題了怎么辦,難道不用你解決問題嗎,如果對 JVM 了解不夠的話,有些問題可能排查起來就很費力,或者根本無法解決。

本篇以 JDK Hotspot 8 為背景,介紹一下 JVM 的常用參數。建議你在做一些小項目、小 demo 的時候,也把這些參數加上,加深印象。以我的經驗來看,有些知識你剛開始接觸的時候會感覺很難理解,但是沒關系,萬事開頭難嘛,知識點都是需要消化時間的。第一天不理解,甚至過了一個月也不理解,但是總有那么一刻,你會突然有種茅塞頓開的感覺,感覺一下子通了。最后心里面感謝自己在多少多少天以前能夠開始學習并堅持學習這些知識點。

只介紹一些常用參數,除了這些常用參數外,Hotspot 還提供了很多其他的參數,每一個都值得考究。

在使用這些參數之前,你需要對 Java 內存模型有一定的了解,可以讀一下這篇文章了解一下內存模型

還是要把內存模型圖放在這里,方便理解。

JVM 你不可不知的參數

堆參數:

-Xms: 堆的初始值,例如 -Xmx2048,初始堆大小為 2G

-Xmx: 堆的最大值,例如 -Xmx2048M,允許最大堆內存 2G

-Xmn: 新生代大小

-XX:SurvivorRatio:Eden 區所占比例,默認是 8,也就是 80%,例如 -XX:SurvivorRatio=8

JVM 你不可不知的參數

最好將 -Xms 和 -Xmx 的值設置成一樣的值,這樣做是為了防止隨著堆空間使用量增加,會動態的調整堆空間大小,有一定的性能損耗,不如開始就設置成相同的值,來規避性能損失。

棧參數

-Xss:棧空間大小,棧是線程獨占的,所以是一個線程使用棧空間的大小,例如 -Xss256K,如果不設置此參數,默認值是 1M,一般來講設置成 256K 就足夠了。

Metaspace 參數

-XX:MetaspaceSize:Metaspace 空間初始大小,如果不設置的話,默認是20.79M,這個初始大小是觸發首次 Metaspace Full GC 的閾值,例如 -XX:MetaspaceSize=256M

-XX:MaxMetaspaceSize:Metaspace 最大值,默認不限制大小,但是線上環境建議設置,例如

-XX:MaxMetaspaceSize=256M

-XX:MinMetaspaceFreeRatio:最小空閑比,當 Metaspace 發生 GC 后,會計算 Metaspace 的空閑比,如果空閑比(空閑空間/當前 Metaspace 大小)小于此值,就會觸發 Metaspace 擴容。默認值是 40 ,也就是 40%,例如 -XX:MinMetaspaceFreeRatio=40

-XX:MaxMetaspaceFreeRatio:最大空閑比,當 Metaspace 發生 GC 后,會計算 Metaspace 的空閑比,如果空閑比(空閑空間/當前 Metaspace 大小)大于此值,就會觸發 Metaspace 釋放空間。默認值是 70 ,也就是 70%,例如 -XX:MaxMetaspaceFreeRatio=70

建議將 MetaspaceSize 和 MaxMetaspaceSize 設置為同樣大小,避免頻繁擴容。

GC 日志

簡單日志

-verbose:gc 或者 -XX:+PrintGC

日志格式:

[GC (Allocation Failure) 7892K->5646K(19456K), 0.0060442 secs]
[GC (Allocation Failure) , 0.0066315 secs]
[Full GC (Allocation Failure) 19302K->13646K(19456K), 0.0032698 secs]

詳細日志

#打印詳細日志
-XX:+PrintGCDetails
#打印 GC 的時間點
-XX:+PrintGCDateStamps

日志格式:

2019-11-13T14:06:46.099-0800: [GC (Allocation Failure) 2019-11-13T14:06:46.099-0800: [DefNew (promotion failed) : 9180K->9157K(9216K), 0.0084297 secs]2019-11-13T14:06:46.107-0800: [Tenured: 10145K->10145K(10240K), 0.0035768 secs] 13802K->13646K(19456K), [Metaspace: 3895K->3895K(1056768K)], 0.0120887 secs] [Times: user=0.00 sys=0.00, real=0.02 secs]
2019-11-13T14:06:47.243-0800: [Full GC (Allocation Failure) 2019-11-13T14:06:47.244-0800: [Tenured: 10145K->10145K(10240K), 0.0042686 secs] 19304K->19146K(19456K), [Metaspace: 3895K->3895K(1056768K)], 0.0043232 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

以下幾個 GC 日志相關的參數打印的內容比較多,生產環境可選擇性開啟,大多數時候不需要開啟。

GC 前后的堆信息

-XX:+PrintHeapAtGC

{Heap before GC invocations=0 (full 0):
def new generation   total 9216K, used 7892K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
eden space 8192K, 96% used [0x00000007bec00000, 0x00000007bf3b5200,
xxx....
class space   used 445K, capacity 462K, committed 512K, reserved 1048576K
Heap after GC invocations=1 (full 0):
def new generation   total 9216K, used 1023K [0x00000007bec00000,
xxx...
Metaspace       used 3892K, capacity 4646K, committed 4864K, reserved 1056768K
class space   used 445K, capacity 462K, committed 512K, reserved 1048576K
}

GC 導致的 Stop the world 時間

-XX:+PrintGCApplicationStoppedTime

Total time for which application threads were stopped: 0.0070384 seconds, Stopping threads took: 0.0000200 seconds

加載類信息

-verbose:class

[Loaded java.net.URLClassLoader$3$1 from /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/lib/rt.jar]

GC 前后的類加載情況

-XX:+PrintClassHistogramBeforeFullGC
-XX:+PrintClassHistogramAfterFullGC

num     #instances         #bytes class name
----------------------------------------------
  1:           140       19016264 [B
  2:         2853         226256 [C
  3:           138         169072 [I
  4:           761         86240 java.lang.Class
  5:         2850         68400 java.lang.String
  6:           660         41024 [Ljava.lang.Object;

日志輸出到文件

以上參數配置好之后,默認會輸出到控制臺或者服務指定的統一日志的位置。但是這里還會有服務的一般性信息日志、錯誤日志等,都混在一起的話會比較亂,所以,一般都會把 jvm 日志單獨存放。

#GC 活動日志,根據配置的參數輸出內容
-Xloggc:/Users/fengzheng/jvmlog/gc.log
#致命錯誤日志,只有在 jvm 發生崩潰的時候會輸出
-XX:ErrorFile=/Users/fengzheng/jvmlog/hs_err_pid%p.log

堆溢出現場保留

有些錯誤雖然不會導致 jvm 崩潰,但是對于服務而言也是非常嚴重的,比如stackOverflow、OutOfMemoryError,發生錯誤后,留存現場信息對分析錯誤原因是至關重要的。jvm 提供了保留堆溢出現場的方法,對于 JDK 8 而言,可能是 heap 溢出,也可能是 Metasapce 溢出。

-XX:HeapDumpPath=/Users/fengzheng/jvmlog
-XX:+HeapDumpOnOutOfMemoryError

最后出現異常后,保存的文件格式為 java_pidxxx.hprof,pid 后面是發生溢出的進程 id,之后可以用 VisualVM、JProfiler 等工具打開分析。

設置垃圾回收器類型

隨著 JDK 版本的升級,可使用的垃圾收集器類型也越來越多了。JDK 8 可使用的垃圾收集器有 7 種,當然有點只適用于年輕代,有點只使用于老年代,JDK 8 中最新的垃圾收集器是 G1,可以用于年輕代和老年代。到了 JDK 11,還出了 ZGC。

下圖是 JDK 8 中可使用的垃圾收集器以及它們配合使用的關系。

JVM 你不可不知的參數

Serial、ParNew、Parallel Scavenge 只適用于年輕代,CMS、Serial Old、Parallel Old 只適用于老年代,而 G1 通用于年輕代和老年代。連線表示它們之間可配合使用的關系,其中 CMS 和 Serial Old 連線的意思是說 Serial Old 會作為 CMS 的后預案,當 CMS 發生 Concurrent Mode Failure 時啟用。

在 JDK 8 中,如果不指定垃圾收集器,默認使用參數 -XX:+UseParallelGC ,新生代使用 Parallel Scavenge,老年代使用 Serial Old。

-XX:+UseSerialGC:使用 Serial + Serial Old ,運行于 client 模式下的默認設置

-XX:+UseConcMarkSweepGC:使用 ParNew+CMS+Serial Old,CMS 垃圾收集器

-XX:+UseParallelGC:Parallel Scavenge + Serial Old,JDK 8 server 模式下的默認設置

-XX:+UseParallelOldGC:Parallel Scavenge + Parallel Old

-XX:+UseG1GC:使用 G1 垃圾收集器

開啟遠程 JMX 監控

除了日志外,當我們需要實時查看 JVM 運行情況的時候怎么辦,當然可以到 JVM 所在服務器jstack、jmap、jinfo 等工具進行查看,但是又不夠直觀,這時候就需要開啟 JMX 遠程功能,使用 jConsole、VisualVM 等工具進行監控。或者自己開發監控平臺,比如我之前就做了一個 web 版的簡易 VisualVm。 無意中就做了個 web 版 JVM 監控端

開啟參數如下:

-Dcom.sun.management.jmxremote
#指定 jvm 所在服務器 ip域名
-Djava.rmi.server.hostname=192.168.1.1
#指定端口
-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.rmi.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

原文 

http://mp.weixin.qq.com/s?__biz=MzAxMjA0MDk2OA==&mid=2449469188&idx=1&sn=c0b78f5432f8ce17276dff3dad2ddd46

本站部分文章源于互聯網,本著傳播知識、有益學習和研究的目的進行的轉載,為網友免費提供。如有著作權人或出版方提出異議,本站將立即刪除。如果您對文章轉載有任何疑問請告之我們,以便我們及時糾正。

PS:推薦一個微信公眾號: askHarries 或者qq群:474807195,里面會分享一些資深架構師錄制的視頻錄像:有Spring,MyBatis,Netty源碼分析,高并發、高性能、分布式、微服務架構的原理,JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源,目前受益良多

轉載請注明原文出處:Harries Blog? » JVM 你不可不知的參數

贊 (0)
分享到:更多 ()

評論 0

  • 昵稱 (必填)
  • 郵箱 (必填)
  • 網址
2013平特肖公式