本篇文章基于Java 6(update 21oder 21之后)版本, HotSpot JVM 提供給了兩個新的參數,在JVM啟動后,在命令行中可以輸出所有XX參數和值。
-XX:+PrintFlagsFinal and -XX:+PrintFlagsInitial
讓我們現在就了解一下新參數的輸出。以 -client 作為參數的 -XX:+PrintFlagsFinal 的結果是一個按字母排序的590個參數表格(注意,每個release版本參數的數量會不一樣)
$ java -client -XX:+PrintFlagsFinal Benchmark
[Global flags]
uintx AdaptivePermSizeWeight = 20 {product}
uintx AdaptiveSizeDecrementScaleFactor = 4 {product}
uintx AdaptiveSizeMajorGCDecayTimeScale = 10 {product}
uintx AdaptiveSizePausePolicy = 0 {product}[...]
uintx YoungGenerationSizeSupplementDecay = 8 {product}
uintx YoungPLABSize = 4096 {product}
bool ZeroTLAB = false {product}
intx hashCode = 0 {product}
(校對注:你可以嘗試在命令行輸入上面的命令,親自實現下)
表格的每一行包括五列,來表示一個XX參數。第一列表示參數的數據類型,第二列是名稱,第四列為值,第五列是參數的類別。第三列”=”表示第四列是參數的默認值,而”:=” 表明了參數被用戶或者JVM賦值了。
注意對于這個例子我只是用了Benchmark類,因為這個系列前面的章節也是用的這個類。甚至沒有一個主類的情況下你能得到相同的輸出,通過運行java 帶另外的參數 -version.現在讓我們檢查下 server VM提供了多少個參數。我們也能指定參數-XX:+UnlockExperimentalVMOptions 和-XX:+UnlockDiagnosticVMOptions ;來解鎖任何額外的隱藏參數。
$ java -server -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal Benchmark
724個參數,讓我們看一眼那些已經被賦值的參數。
$ java -server -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal Benchmark | grep ":"
uintx InitialHeapSize := 57505088 {product}
uintx MaxHeapSize := 920649728 {product}
uintx ParallelGCThreads := 4 {product}
bool PrintFlagsFinal := true {product}
bool UseParallelGC := true {product}
(校對注:這個命令非常有用)我們僅設置一個自己的參數 -XX:+PrintFlagsFinal。其他參數通過server VM基于系統設置的,以便以合適的堆大小和GC設置運行。
如果我們只想看下所有XX參數的默認值,能夠用一個相關的參數,-XX:+PrintFlagsInitial 。 用 -XX:+PrintFlagsInitial, 只是展示了第三列為“=”的數據(也包括那些被設置其他值的參數)。
然而,注意當與-XX:+PrintFlagsFinal 對比的時候,一些參數會丟失,大概因為這些參數是動態創建的。
研究表格的內容是很有意思的,通過比較client和server VM的行為,很明顯了解哪些參數會影響其他的參數。有興趣的讀者,可以看一下這篇不錯文章Inspecting HotSpot JVM Options。這個文章主要解釋了第五列的參數類別。
-XX:+PrintCommandLineFlags
讓我們看下另外一個參數,事實上這個參數非常有用: -XX:+PrintCommandLineFlags。這個參數讓JVM打印出那些已經被用戶或者JVM設置過的詳細的XX參數的名稱和值。
換句話說,它列舉出 -XX:+PrintFlagsFinal的結果中第三列有":="的參數。以這種方式,我們可以用-XX:+PrintCommandLineFlags作為快捷方式來查看修改過的參數。看下面的例子。
$ java -server -XX:+PrintCommandLineFlags Benchmark
-XX:InitialHeapSize=57505088 -XX:MaxHeapSize=920081408 -XX:ParallelGCThreads=4 -XX:+PrintCommandLineFlags -XX:+UseParallelGC
現在如果我們每次啟動java 程序的時候設置 -XX:+PrintCommandLineFlags 并且輸出到日志文件上,這樣會記錄下我們設置的JVM 參數對應用程序性能的影響。類似于 -showversion(見 Part1),我建議 –XX:+PrintCommandLineFlags 這個參數應該總是設置在JVM啟動的配置項里。因為你從不知道你什么時候會需要這些信息。
奇怪的是在這個例子中,通過 -XX:+PrintCommandLineFlags 列出堆的最大值會比通過-XX:+PrintFlagsFinal列舉出的相應值小一點。
- java
- 設計模式
- 設計模式總覽
- 設計原則
- 工廠方法模式
- 抽象工廠模式
- 單例模式
- 建造者模式
- 原型模式
- 適配器模式
- 裝飾者模式
- 代理模式
- 外觀模式
- 橋接模式
- 組合模式
- 享元模式
- 策略模式
- 模板方法模式
- 觀察者模式
- 迭代子模式
- 責任鏈模式
- 命令模式
- 備忘錄模式
- 狀態模式
- 訪問者模式
- 中介者模式
- 解釋器模式
- 附錄
- JVM相關
- JVM內存結構
- Java虛擬機的內存組成以及堆內存介紹
- Java堆和棧
- 附錄-數據結構的堆棧和內存分配的堆區棧區的區別
- Java內存之Java 堆
- Java內存之虛擬機和內存區域概述
- Java 內存之方法區和運行時常量池
- Java 內存之直接內存(堆外內存)
- JAVA內存模型
- Java內存模型介紹
- 內存模型如何解決緩存一致性問題
- 深入理解Java內存模型——基礎
- 深入理解Java內存模型——重排序
- 深入理解Java內存模型——順序一致性
- 深入理解Java內存模型——volatile
- 深入理解Java內存模型——鎖
- 深入理解Java內存模型——final
- 深入理解Java內存模型——總結
- 內存可見性
- JAVA對象模型
- JVM內存結構 VS Java內存模型 VS Java對象模型
- Java的對象模型
- Java的對象頭
- HotSpot虛擬機
- HotSpot虛擬機對象探秘
- 深入分析Java的編譯原理
- Java虛擬機的鎖優化技術
- 對象和數組并不是都在堆上分配內存的
- 垃圾回收
- JVM內存管理及垃圾回收
- JVM 垃圾回收器工作原理及使用實例介紹
- JVM內存回收理論與實現(對象存活的判定)
- JVM參數及調優
- CMS GC日志分析
- JVM實用參數(一)JVM類型以及編譯器模式
- JVM實用參數(二)參數分類和即時(JIT)編譯器診斷
- JVM實用參數(三)打印所有XX參數及值
- JVM實用參數(四)內存調優
- JVM實用參數(五)新生代垃圾回收
- JVM實用參數(六) 吞吐量收集器
- JVM實用參數(七)CMS收集器
- JVM實用參數(八)GC日志
- Java性能調優原則
- JVM 優化經驗總結
- 面試題整理
- 面試題1
- java日志規約
- Spring安全
- OAtuth2.0簡介
- Spring Session 簡介(一)
- Spring Session 簡介(二)
- Spring Session 簡介(三)
- Spring Security 簡介(一)
- Spring Security 簡介(二)
- Spring Security 簡介(三)
- Spring Security 簡介(四)
- Spring Security 簡介(五)
- Spring Security Oauth2 (一)
- Spring Security Oauth2 (二)
- Spring Security Oauth2 (三)
- SpringBoot
- Shiro
- Shiro和Spring Security對比
- Shiro簡介
- Session、Cookie和Cache
- Web Socket
- Spring WebFlux