常用的JVM配置參數(shù)

一、Trace 跟蹤參數(shù)

在Eclipse中，如何打開GC的監(jiān)控日志
　　　　選擇菜單欄Run -> Run Configurations -> Java Application -> 選擇自己的項目 -> 在右側(cè)找到Arguments選項卡 -> 在VM arguments中填寫參數(shù)，具體參數(shù)在下面會有說明。

image

根據(jù)右側(cè)Main的project和下面Main class確定自己監(jiān)控的main方法

image

在右側(cè)找到Arguments選項卡 -> 在VM arguments中填寫參數(shù)

image

  • -verbose:gc(打開GC的跟蹤日志)

  • -XX:+printGC(打開GC的log的開關(guān)，簡要日志)

image

上圖為我自己的一個小項目中的gc簡要的日志信息 其中 9865k 表示在堆中GC之前使用了9865k的空間，2891k 表示GC之后使用2891k的空間，剩空間為19456k ，本次GC使用的時間為0.0021802 secs

  • -XX:+PrintGCDetails(打印GC的詳細(xì)信息)
image

上圖我們以第二條為例：PSYoungGen表示新生代 GC之前為9214k，GC之后為 1016K，新生代總大小為9216k，GC所使用的時間為0.0016505 secs。而后面的信息則為上面簡要信息中的內(nèi)容。user 總計本次 GC 總線程所占用的總 CPU 時間 ，sys – OS 調(diào)用 or 等待系統(tǒng)時間，real – 應(yīng)用暫停時間，如果GC 線程是 Serial Garbage Collector單線程的方式的話， real time 等于user 和 system 時間之和.

image

（def new generation）新生代
（total 13824K）共有13824K空間可用，（used 11223K）有11223K被使用。
（eden space 12288k.91%）伊甸區(qū) 對象出生的地方有 12288K 的空間，有91%已經(jīng)被占用
（from space 1536K，0%）s0區(qū) 1536K空間，被占用為0
（to space 1536K，0%）s0區(qū) 1536K空間，被占用為0
（tenured generation）老年代
（the space 5120K，0%）有5120K空間被占用為0
（compacting perm gen）永久代
（the space 12288k，1%）有12288K空間被占用為1%，在jdk5.0之后在串行GC下有一個永久區(qū)共享，打開共享之后一些基礎(chǔ)的java類可用被所有的jvm共同使用，所以被占用率較小.
（ro space 10240K，44%）只讀共享區(qū)間 有10240K空間 44%被占用
（rw space 12288K，52%）可讀可寫共享區(qū)間 有12288K空間，52%被占用

（而最后[]號中的3個值為地址值，分別表示當(dāng)前內(nèi)存區(qū)域的地址開始地址，當(dāng)前地址，最大地址上限）

image

上圖為我自己獲取到的jvm日志信息，永久代被刪除，取而代之的是Metaspace 元數(shù)據(jù)區(qū)域，這是 java8 所做的替換。

持久代中存的內(nèi)容：

  1. JVM中類的元數(shù)據(jù)在Java堆中的存儲區(qū)域。
  2. Java類對應(yīng)的HotSpot虛擬機(jī)中的內(nèi)部表示。
  3. 類的層級信息，字段，名字。
  4. 方法的編譯信息及字節(jié)碼。
  5. 變量
  6. 常量池和符號解析

元空間的特點：

  1. 充分利用了Java語言規(guī)范中的好處：類及相關(guān)的元數(shù)據(jù)的生命周期與類加載器的一致。
  2. 每個加載器有專門的存儲空間
  3. 只進(jìn)行線性分配
  4. 不會單獨回收某個類
  5. 省掉了GC掃描及壓縮的時間
  6. 元空間里的對象的位置是固定的
  7. 如果GC發(fā)現(xiàn)某個類加載器不再存活了，會把相關(guān)的空間整個回收掉

  • -XX:+PrintGCTimeStamps(打印GC發(fā)生的時間戳)

  • -Xloggc:log/ge.log(指定GC.log的位置，以文件形式輸出)

  • -XX:+PrintHeapAtGC（每一次GC后都打印出堆信息）

image

Heap before GC 表示GC之前的堆信息
　　 Heap after GC 表示GC之后的堆信息

  • -XX:+TraceClassLoading（監(jiān)控類加載，可以在程序運行時檢出哪些類被加載了）
image
  • -XX:+PrintClassHistogram（加入此參數(shù)，在運行時不會有其他東西輸出，但是在按下Ctrl+Break后可以打印出類的信息，類的直方圖）
image

上述4個列分別代表了（num）序號,（instances）實例數(shù)量,(bytes)總占用空間，（class name）類型
　　　　（[B）有890617個byte數(shù)組，占用了470266000的空間
　　　　（java.util.HashMap$Node）hashMap的結(jié)點有890643個占用21375432的空間

二、堆的分配參數(shù)

  • -Xmx（最大堆的空間）
  • -Xms（最小堆的空間）
image

<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">System.out.println("系統(tǒng)最大使用空間：Xmx=" + Runtime.getRuntime().maxMemory()/1024.0/1024 + "M");
System.out.println("系統(tǒng)可用空間：free mem=" + Runtime.getRuntime().freeMemory()/1024.0/1024 + "M");
System.out.println("系統(tǒng)中分配到的空間：total mem=" + Runtime.getRuntime().totalMemory()/1024.0/1024 + "M");</pre>

我們可以通過上述代碼來獲取系統(tǒng)中實際使用的空間大小。

image

我們可以看到，我的系統(tǒng)中最大堆空間為18.0M，系統(tǒng)分配到的空間為9.5M，是比較接近于我們自己設(shè)置的值，系統(tǒng)目前可用空間為7.9M，此時系統(tǒng)存在可用空間。
　　當(dāng)我在我的系統(tǒng)中加入一行代碼，創(chuàng)建一個1M的byte數(shù)組

<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">byte []b = new byte[102410241];</pre>

image

此時發(fā)現(xiàn)，系統(tǒng)可用空間整好少了1M，而總空間和系統(tǒng)中分配到的空間還是沒變的，如果我們的系統(tǒng)使用的空間是小于系統(tǒng)分配的空間時，系統(tǒng)分配空間會盡可能維持在最小空間10M附近，只有系統(tǒng)使用的空間大于10M后，系統(tǒng)分配空間才會去擴(kuò)展。我們在代碼中創(chuàng)建一個10M的byte數(shù)組來看。

image

此時，系統(tǒng)使用的空間肯定是大于10M的，所以我們的系統(tǒng)分配的空間已經(jīng)擴(kuò)展到了16M.如果我們創(chuàng)建一個大于20Mbyte的話就會發(fā)生OOM了，因為系統(tǒng)已經(jīng)限制最大空間為20M。

image
  • -Xmn (設(shè)置新生代的大小)
  • -XX:NewRatio（設(shè)置新生代和老年代的比值，如果設(shè)置為4則表示（eden+from（或者叫s0）+to（或者叫s1））： 老年代 =1：4），即年輕代占堆的五分之一
  • -XX:SurvivorRatio（設(shè)置兩個Survivor（幸存區(qū)from和to或者叫s0或者s1區(qū)）和eden區(qū)的比），8表示兩個Survivor：eden=2:8，即Survivor區(qū)占年輕代的五分之一

下面來看一個例子（jdk6）

<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">//將jvm參數(shù)設(shè)置為-Xmx20m -Xms20m -Xmn1m -XX:+PrintGCDetails（將新生代的大小設(shè)置為1M）
byte []b = null; for (int i = 0; i < 10; i++) {
b = new byte[102410241];
}</pre>

image

上圖為堆信息，沒有發(fā)生過GC，新生代只有896K，1Mbyte無法分配到新生區(qū)，所以所有的數(shù)據(jù)都被分配到老年代，老年代的內(nèi)存被占用的為10240K正好是byte的大小。
　　我們將上述代碼的新生代的內(nèi)存進(jìn)行擴(kuò)大，調(diào)整到15M -Xmx20m -Xms20m -Xmn15m -XX:+PrintGCDetails

image

我們發(fā)現(xiàn)修改新生代之后也沒有發(fā)生GC，而是將數(shù)據(jù)全部分配到了新生代13824K，老年代卻沒有使用。

我們將上述代碼的新生代的內(nèi)存進(jìn)行減小，調(diào)整到不大不小的位置，調(diào)整到7M -Xmx20m -Xms20m -Xmn7m -XX:+PrintGCDetails

image

此時發(fā)現(xiàn)GC被觸發(fā)了2次，第一次回收了3M左右，第二次回收了4M左右，此時發(fā)現(xiàn)新生代被使用1139K，老年代被使用2507K，因為form to（s0 s1）區(qū)域的大小為704K，不足1M所以才GC時還是有一部分?jǐn)?shù)據(jù)被放入了老年代。

接下來，我們將幸存代的大小進(jìn)行調(diào)整from：to：endn=1：1：2， -Xmx20m -Xms20m -Xmn7m XX:SurvivorRatio=2 -XX:+PrintGCDetails

image

此時幸存代可以正常使用，GC發(fā)生了3次。第一次回收了1M，第二次回收了3M，第三次回收了3M，新生代占用了3M，此時新產(chǎn)生的數(shù)據(jù)沒有進(jìn)入到老年代。

接下來，繼續(xù)調(diào)整新生代和老年代的比例為1， -Xmx20m -Xms20m -XX:NewRatio=1 XX:SurvivorRatio=2 -XX:+PrintGCDetails

image

此時GC進(jìn)行了2次回收第一次回收了3M，第二次回收了4M，還有3M在新生代，也沒有數(shù)據(jù)進(jìn)入老年代，并且GC只執(zhí)行了2次，所以對于上一種配置效率就有所提高，因為GC時很消耗效率的。幸存代空間越大，對系統(tǒng)資源的浪費還是挺嚴(yán)重的，所以合理的分配幸存代，堆系統(tǒng)的效率也會有很大的幫助。

接下來，繼續(xù)調(diào)整幸存代的大小進(jìn)行調(diào)整from：to：endn=1：1：3， -Xmx20m -Xms20m -XX:NewRatio=1 XX:SurvivorRatio=3 -XX:+PrintGCDetails，此時，from和to的幸存區(qū)有2M，而endn區(qū)有6M

image

此時GC只進(jìn)行了1次，我們對幸存代的大小進(jìn)行了合理的減小，這樣更有利于內(nèi)存的合理使用。

  • -XX:+HeapDumpOnOutOfMemoryError(將OOM時的堆信息導(dǎo)出到文件)
    如果系統(tǒng)出現(xiàn)OOM一般情況系統(tǒng)有可能會down掉，但是我們排查問題時需要場景重現(xiàn)是比較困難的，所以當(dāng)我們輸出了OOM的異常時，就可以直接查看，找出導(dǎo)致OOM的原因

  • -XX:+HeapDumpPath=XXXX(導(dǎo)出OOM堆信息文件的路徑)

  • -XX:OnOutOfMemoryError(在系統(tǒng)出現(xiàn)OOM時，執(zhí)行一個腳本，可以發(fā)送郵件，報警或者是重啟程序)

  • -XX:PermSize（設(shè)置永久代的初始空間大小）

  • -XX:MaxParmSize（設(shè)置永久代的最大空間）

在使用CGLIB等庫的時候，可能會產(chǎn)生大量的類，這些類就有可能會撐爆永久區(qū)導(dǎo)致OOM
　　　　我們來看下面實例：

<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">for (int i = 0; i < 100000; i++) {
CglibBean c = new CglibBean(new HashMap<String, String>());
}</pre>

image

當(dāng)發(fā)生OOM時，我們發(fā)現(xiàn)永久區(qū)的空間已經(jīng)是滿了，然后發(fā)生GC時永久區(qū)的內(nèi)容也無法被回收，所以導(dǎo)致了OOM，此時新生代只占用了2%，老難帶占用了20%，而老年代使用率為99%.

總結(jié)：

  • 根據(jù)實際事情調(diào)整新生代和幸存代的大小，因為各個系統(tǒng)的情況都不一樣，所以需要自己調(diào)試而找到一個相對較優(yōu)的分配方案。
  • 官方推薦新生代占堆的3/8
  • 幸存代占新生代的1/10
  • 在OOM時，及得Dump出堆，確保可以排查現(xiàn)場問題
  • 在堆空間沒有使用完時也有可能會產(chǎn)生OOM，此時有可能是永久代被撐爆。

三、棧大小的分配

棧是每一個線程都有的，他是線程私有的一塊內(nèi)存區(qū)域.棧中主要是由幀組成，而幀中是每個方法的局部變量表，操作數(shù)表，和指向常量池的引用和返回地址等組成。一般只有幾百K，但是它的大小決定了線程的多少和調(diào)用函數(shù)的深度，而且每個線程都有獨立的棧空間。

  • -Xss（設(shè)置棧空間的大小）
    下面看一個簡單的例子：首先我們將棧空間設(shè)置為128K

[
復(fù)制代碼

](javascript:void(0); "復(fù)制代碼")

<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">private static int count = 0; public static void recursion(long a, long b, long c) { long e = 1, f = 2, g = 3, h = 4, i = 5, j = 6, k = 7, l = 8, m = 9;
count ++;
recursion(a, b, c);
} public static void main(String[] args) { try {
recursion(1, 2, 3);
} catch (Throwable e) {
System.out.println("deep of calling = " + count);
e.printStackTrace();
}
}</pre>

[
復(fù)制代碼

](javascript:void(0); "復(fù)制代碼")

image

此時只執(zhí)行了323次的遞歸。

　　然后我們將棧空間擴(kuò)大到256K再來看結(jié)果：

image

此時遞歸執(zhí)行竟然擴(kuò)大到了1019，接近3倍，那么說明方法執(zhí)行的深度由棧空間的大小所決定。

然后我們將局部變量e之后的局部變量都清除再來看結(jié)果：

image

我們發(fā)現(xiàn)，遞歸次數(shù)再次增加。此處說明方法執(zhí)行的深度也由方法內(nèi)局部變量表的個數(shù)所決定。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

推薦閱讀更多精彩內(nèi)容