概述

在這篇文章中，我們將一起看一下，一些常見的JAVA虛擬機(jī)的參數(shù)配置。

堆內(nèi)存 - Xms 和 Xmx配置

堆內(nèi)存配置，可以說是應(yīng)用程序中，最常見的提升性能的參數(shù)配置。

這就是為什么我們需要指定最大和最小堆內(nèi)存配置：

-Xms<heap size>[unit] 
-Xmx<heap size>[unit]

在這里，unit 表示要初始化內(nèi)存(用堆大小表示)的單元。單位可以標(biāo)記為“ g”代表 GB，“ m”代表 MB，“ k”代表 KB。

例如，如果我們想給 JVM 分配最小的2gb 和最大的5Gb，我們需要寫:

-Xms2G -Xmx5G

從 java8開始，Metaspace 的大小沒有定義。一旦它達(dá)到全局限制，JVM 會(huì)自動(dòng)增加它，然而，為了克服任何不必要的不穩(wěn)定性，我們可以設(shè)置 Metaspace 大小為:

-XX:MaxMetaspaceSize=<metaspace size>[unit]

在這里，metaspace size表示我們要分配給元空間的內(nèi)存量。

根據(jù) Oracle 的參考指南，除了總的可用內(nèi)存之外，第二大影響因素是為年輕代保留的堆的比例。默認(rèn)情況下，YG(年輕代) 的最小大小為1310 MB，最大大小不受限制。

我們也可以顯示的設(shè)置年輕代的大小：

-XX:NewSize=<young size>[unit] 
-XX:MaxNewSize=<young size>[unit]

垃圾收集

為了提高應(yīng)用程序的穩(wěn)定性，選擇正確的垃圾收集算法至關(guān)重要。有四種類型的 GC 實(shí)現(xiàn):

Serial Garbage Collector 串行垃圾收集器
Parallel Garbage Collector 并行垃圾收集器
CMS Garbage Collector CMS垃圾收集器
G1 Garbage Collector G1垃圾收集器

這些實(shí)現(xiàn)可以使用以下參數(shù)聲明:

-XX:+UseSerialGC
-XX:+UseParallelGC
-XX:+USeParNewGC
-XX:+UseG1GC

GC 日志

為了嚴(yán)格監(jiān)視應(yīng)用程序的運(yùn)行狀況，我們應(yīng)該始終檢查 JVM 的垃圾收集性能。最簡單的方法是以可讀的格式記錄 GC 日志。

使用以下參數(shù)，我們可以記錄 GC 活動(dòng):

-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=< number of log files > 
-XX:GCLogFileSize=< file size >[ unit ]
-Xloggc:/path/to/gc.log

在這里，UseGCLogFileRotation 指定日志文件滾動(dòng)策略，很像 log4j、 sl4j 等。 NumberOfGCLogfFles 表示可以為單個(gè)應(yīng)用程序生命周期編寫的日志文件的最大數(shù)量。 GCLogFileSize 指定文件的最大大小。最后，loggc 表示它的位置。

這里需要注意的是，還有兩個(gè)可用的 JVM 參數(shù)(- XX: + PrintGCTimeStamps 和-XX: + PrintGCDateStamps)可用于在 GC 日志中打印日期時(shí)間戳。

例如，如果我們希望分配最多100個(gè) GC 日志文件，每個(gè)文件的最大大小為50 MB，并希望將它們存儲(chǔ)在‘/home/user/log/ ’位置，我們可以使用以下語法:

-XX:+UseGCLogFileRotation  
-XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=50M 
-Xloggc:/home/user/log/gc.log

但是，問題是總是在后臺(tái)使用一個(gè)附加的守護(hù)進(jìn)程來監(jiān)視系統(tǒng)時(shí)間。這種行為可能會(huì)造成一些性能瓶頸; 這就是為什么在生產(chǎn)中最好不要使用這個(gè)參數(shù)的原因。

OOM的處理

對(duì)于大型應(yīng)用程序來說，遇到OOM是非常常見的，OOM會(huì)導(dǎo)致應(yīng)用程序崩潰。這是一個(gè)非常關(guān)鍵的場(chǎng)景，很難復(fù)制以解決問題。

這就是為什么 JVM 提供了一些參數(shù)，這些參數(shù)將堆內(nèi)存轉(zhuǎn)儲(chǔ)到一個(gè)物理文件中，以后可以用來查找內(nèi)存泄漏:

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=./java_pid<pid>.hprof
-XX:OnOutOfMemoryError="< cmd args >;< cmd args >" 
-XX:+UseGCOverheadLimit

這里有幾點(diǎn)需要注意:

HeapDumpOnOutOfMemoryError: 這個(gè)參數(shù)表示如果發(fā)生OOM，則指示 JVM 將 heap 轉(zhuǎn)儲(chǔ)到物理文件
HeapDumpPath: 這個(gè)參數(shù)表示要寫入文件的路徑, 文件名任意; 但是，如果 JVM 在名稱中找到一個(gè) pid 標(biāo)記，導(dǎo)致內(nèi)存不足錯(cuò)誤的當(dāng)前進(jìn)程的進(jìn)程 id 將會(huì)以Hprof 格式附加到文件名中
OnOutOfMemoryError: 這個(gè)參數(shù)用于發(fā)出緊急命令，以便在內(nèi)存不足的情況下執(zhí)行; 在 cmd args 中應(yīng)使用適當(dāng)?shù)拿睢?例如，如果我們想在內(nèi)存不足時(shí)重啟服務(wù)器，我們可以設(shè)置參數(shù):

-XX:OnOutOfMemoryError="shutdown -r"

UseGCOverheadLimit: 該參數(shù)是一種策略，它限制在拋出 OutOfMemory 錯(cuò)誤之前，在 GC 中花費(fèi)的 VM 時(shí)間的比例

32/64位

在同時(shí)安裝了32位和64位包的操作系統(tǒng)環(huán)境中，JVM 會(huì)自動(dòng)選擇32位環(huán)境包。如果我們想手動(dòng)設(shè)置環(huán)境為64位，我們可以使用下面的參數(shù):

-d<OS bit>

Misc(其他一些參數(shù))

-server: 表示啟用 HotSpot 虛擬機(jī), 該參數(shù)在64位系統(tǒng)中默認(rèn)使用
-XX:+UseStringDeduplication: java 8u20版本引入了這個(gè) JVM 參數(shù)，用來減少通過創(chuàng)建太多相同 String 的實(shí)例帶來的不必要的內(nèi)存使用; 這通過將重復(fù)的 String 值減少為單個(gè)全局 char []數(shù)組來優(yōu)化堆內(nèi)存
-XX:+UseLwpsynchronization: 設(shè)置基于 LWP (輕量級(jí)進(jìn)程)的同步策略，而不是基于線程的同步策略
-XX:LargePageSizeInBytes: 設(shè)置用于 Java 堆的 Large Page大小; 它采用 gb / mb / kb 的參數(shù); 使用較大的頁面大小，我們可以更好地利用虛擬內(nèi)存硬件資源; 然而，這可能會(huì)導(dǎo)致 PermGen 的空間大小變大，這反過來會(huì)迫使減小 Java 堆空間的大小
-XX:MaxHeapFreeRatio: 設(shè)置 GC 之后堆空閑的最大百分比，以避免收縮。
-XX:MinHeapFreeRatio: 設(shè)置 GC 之后堆空閑的最小百分比，以避免擴(kuò)展; 為了監(jiān)視堆使用情況，可以使用 JDK 附帶的 VisualVM。
-XX:SurvivorRatio: Eden區(qū)和幸存者空間大小的比率——例如,-XX:SurvivorRatio=6 將每個(gè)幸存者空間和Eden區(qū)的比率設(shè)置為1:6
-XX:+UseLargePages: 如果系統(tǒng)支持, 則使用大的頁面內(nèi)存，請(qǐng)注意，如果使用這個(gè) JVM 參數(shù)，OpenJDK 7會(huì)崩潰
-XX:+UseStringCache: 啟用 String 池中可用的常用分配字符串的緩存
-XX:+UseCompressedStrings: 對(duì) String 對(duì)象使用 byte []類型，該類型可以用純 ASCII 格式表示
-XX:+OptimizeStringConcat: 它在可能的情況下優(yōu)化字符串串聯(lián)操作