天天看點
傳回

GC調優執行個體1.2、JVM的GC機制四、GC調優的小例子

關于 jconsole的分析:

連接配接之後,我們要關注以下幾個方面

1. 概述

GC調優執行個體1.2、JVM的GC機制四、GC調優的小例子

如上圖.   我們可以看到有兩個垃圾收集器: ParNew 和 ConcurrentMarkSweep . 第一個是minor gc 第二個是full gc. 第一個經常啟動,不會對性能造成壞的影響,第二個在old區很高的時候會啟動,啟動的時候會導緻JVM暫停響應...

2. 記憶體 監控(堆記憶體) JCONSOLE最重要的作用之一就是監控記憶體是否有洩露,也就是記憶體釋放是否正常.

GC調優執行個體1.2、JVM的GC機制四、GC調優的小例子

如上圖,5個柱圖,由左到右分别是:  CMS Old Gen、Par Eden Space、Par Survivor Space、Code Cache、CMS Perm Gen

在正常情況下，eden會占用較高，Survivor占用較低 ，old 占用很低； 如果發現old占用節節增高，那麼很可能存在記憶體洩露。

另外補充一下 JVM GC的一些知識

GC調優執行個體1.2、JVM的GC機制四、GC調優的小例子

如上圖 JVM 将記憶體分為兩大塊 Young Generation 和 Old Generation

其中 Young Generation 又分為Eden  Space 和 Survivor Space(又分為From 和 To兩塊)

1.1、記憶體配置設定原則：

1、對象優先在EDEN配置設定,這裡的大部分對象朝生夕滅，Minor GC主要清理該處

2、大對象（占記憶體大）、長期存活的對象（使用頻繁）将直接進入老年代Full GC的主要清理該處

3、适齡對象也可能進入老年代,判斷是否适齡采用動态年齡判斷方法.(動态對象年齡判斷：

當Survivor空間的某個年齡a的所有對象大小總和大于Survivor空間的一半，年齡大于或等于a的對象就可以直接進入老年代)

1.2、JVM的GC機制

JVM有2個GC線程

第一個線程負責回收Heap的Young區 （minor GC）

第二個線程在Heap不足時（小于-Xms的值），周遊Heap，将Young 區更新為Older區 （FULL GC）。Older區的大小等于-Xmx減去-Xmn，是以不能将-Xms的值設的過大，因為第二個線程被迫運作會降低JVM的性能。

四、GC調優的小例子

例1：Heap size 設定

JVM 堆的設定是指java程式運作過程中JVM可以調配使用的記憶體空間的設定.JVM在啟動的時候會自動設定Heap size的值，其初始空間(即-Xms)是實體記憶體的1/64，最大空間(-Xmx)是實體記憶體的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項可進行設定。

Heap size 的大小是Young Generation 和Tenured Generaion 之和。

當在JAVA_HOME下demo/jfc/SwingSet2/目錄下執行下面的指令。

[java] view plaincopy

  1. java -jar -Xmn4m -Xms16m -Xmx16m SwingSet2.jar

[java] view plaincopy

  1. java -jar -Xmn4m -Xms16m -Xmx16m SwingSet2.jar  
java -jar -Xmn4m -Xms16m -Xmx16m SwingSet2.jar

系統輸出為：

[java] view plaincopy

  1. Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap space
  2. Exception in thread "Image Fetcher 3" java.lang.OutOfMemoryError: Java heap space
  3. Exception in thread "Image Fetcher 1" java.lang.OutOfMemoryError: Java heap space
  4. Exception in thread "Image Fetcher 2" java.lang.OutOfMemoryError: Java heap space

[java] view plaincopy

  1. Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap space 
  2. Exception in thread "Image Fetcher 3" java.lang.OutOfMemoryError: Java heap space 
  3. Exception in thread "Image Fetcher 1" java.lang.OutOfMemoryError: Java heap space 
  4. Exception in thread "Image Fetcher 2" java.lang.OutOfMemoryError: Java heap space 

  1. Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap space

  2. Exception in thread "Image Fetcher 3" java.lang.OutOfMemoryError: Java heap space

  3. Exception in thread "Image Fetcher 1" java.lang.OutOfMemoryError: Java heap space

  4. Exception in thread "Image Fetcher 2" java.lang.OutOfMemoryError: Java heap space

除了這些異常資訊外，還會發現程式的響應速度變慢了。這說明Heap size 設定偏小，GC占用了更多的時間，而應用配置設定到的執行時間較少。

提示：在JVM中如果98％的時間是用于GC且可用的Heap size 不足2％的時候将抛出此異常資訊。

将上面的指令換成以下指令執行則應用能夠正常使用，且未抛出任何異常。

java -jar -Xmn4m -Xms16m -Xmx32m SwingSet2.jar

提示：Heap Size 最大不要超過可用實體記憶體的80％，一般的要将-Xms和-Xmx選項設定為相同，而-Xmn為1/4的-Xmx值。

例2：Young Generation（-Xmn）的設定

在本例中看一下Young Generation的設定不同将有什麼現象發生。

假設将Young generation 的大小設定為4M ，即執行java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar，

螢幕輸出如下（節選）

[java] view plaincopy

  1. [GC [DefNew: 3968K->64K(4032K), 0.0923407 secs] 3968K->2025K(32704K),0.0931870 secs]
  2. [GC [DefNew: 4021K->64K(4032K), 0.0356847 secs] 5983K->2347K(32704K),0.0365441 secs]
  3. [GC [DefNew: 3995K->39K(4032K), 0.0090603 secs] 6279K->2372K(32704K),0.0093377 secs]

[java] view plaincopy

  1. [GC [DefNew: 3968K->64K(4032K), 0.0923407 secs] 3968K->2025K(32704K), 0.0931870 secs] 
  2. [GC [DefNew: 4021K->64K(4032K), 0.0356847 secs] 5983K->2347K(32704K), 0.0365441 secs] 
  3. [GC [DefNew: 3995K->39K(4032K), 0.0090603 secs] 6279K->2372K(32704K), 0.0093377 secs] 

  1. [GC [DefNew: 3968K->64K(4032K), 0.0923407 secs] 3968K->2025K(32704K), 0.0931870 secs]

  2. [GC [DefNew: 4021K->64K(4032K), 0.0356847 secs] 5983K->2347K(32704K), 0.0365441 secs]

  3. [GC [DefNew: 3995K->39K(4032K), 0.0090603 secs] 6279K->2372K(32704K), 0.0093377 secs]

将程式體制并将Young Generation的大小設定為8M，即執行

[java] view plaincopy

  1. java -jar -verbose:gc -Xmn8m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar

[java] view plaincopy

  1. java -jar -verbose:gc -Xmn8m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar  
java -jar -verbose:gc -Xmn8m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar

螢幕輸出如下（節選）

[java] view plaincopy

  1. [GC [DefNew: 7808K->192K(8000K), 0.1016784 secs] 7808K->2357K(32576K),0.1022834 secs]
  2. [GC [DefNew: 8000K->70K(8000K), 0.0149659 secs] 10165K->2413K(32576K),0.0152557 secs]
  3. [GC [DefNew: 7853K->59K(8000K), 0.0069122 secs] 10196K->2403K(32576K),0.0071843 secs]
  4. [GC [DefNew: 7867K->171K(8000K), 0.0075745 secs] 10211K->2681K(32576K),0.0078376 secs]
  5. [GC [DefNew: 7970K->192K(8000K), 0.0201353 secs] 10480K->2923K(32576K),0.0206867 secs]
  6. [GC [DefNew: 7979K->30K(8000K), 0.1787079 secs] 10735K->4824K(32576K),0.1790065 secs]

[java] view plaincopy

  1. [GC [DefNew: 7808K->192K(8000K), 0.1016784 secs] 7808K->2357K(32576K), 0.1022834 secs] 
  2. [GC [DefNew: 8000K->70K(8000K), 0.0149659 secs] 10165K->2413K(32576K), 0.0152557 secs] 
  3. [GC [DefNew: 7853K->59K(8000K), 0.0069122 secs] 10196K->2403K(32576K), 0.0071843 secs] 
  4. [GC [DefNew: 7867K->171K(8000K), 0.0075745 secs] 10211K->2681K(32576K), 0.0078376 secs] 
  5. [GC [DefNew: 7970K->192K(8000K), 0.0201353 secs] 10480K->2923K(32576K), 0.0206867 secs] 
  6. [GC [DefNew: 7979K->30K(8000K), 0.1787079 secs] 10735K->4824K(32576K), 0.1790065 secs] 

  1. [GC [DefNew: 7808K->192K(8000K), 0.1016784 secs] 7808K->2357K(32576K), 0.1022834 secs]

  2. [GC [DefNew: 8000K->70K(8000K), 0.0149659 secs] 10165K->2413K(32576K), 0.0152557 secs]

  3. [GC [DefNew: 7853K->59K(8000K), 0.0069122 secs] 10196K->2403K(32576K), 0.0071843 secs]

  4. [GC [DefNew: 7867K->171K(8000K), 0.0075745 secs] 10211K->2681K(32576K), 0.0078376 secs]

  5. [GC [DefNew: 7970K->192K(8000K), 0.0201353 secs] 10480K->2923K(32576K), 0.0206867 secs]

  6. [GC [DefNew: 7979K->30K(8000K), 0.1787079 secs] 10735K->4824K(32576K), 0.1790065 secs]

那麼根據GC輸出的資訊（這裡取第一行）做一下Minor收集的比較。可以看出兩次的Minor收集分别在Young generation中找回3904K（3968K->64K）和7616K(7808K->192K)而對于整個jvm則找回 1943K（3968K->2025）和5451K（7808K->2357K）。第一種情況下Minor收集了大約50％（1943/3904）的對象，而另外的50％的對象則被移到了tenured generation。在第二中情況下Minor收集了大約72％的對象，隻有不到30％的對象被移到了Tenured Generation.這個例子說明此應用在的Young generation 設定為4m時顯的偏小。

提示：一般的Young Generation的大小是整個Heap size的1/4。Young generation的minor收集率應一般在70％以上。當然在實際的應用中需要根據具體情況進行調整。

例3：Young Generation對應用響應的影響

還是使用-Xmn4m 和-Xmn8m進行比較，先執行下面的指令

[java] view plaincopy

  1. java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime SwingSet2.jar

[java] view plaincopy

  1. java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime SwingSet2.jar  
java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime SwingSet2.jar

螢幕輸出如下（節選）

[java] view plaincopy

  1. Application time: 0.5114944 seconds
  2. [GC [DefNew: 3968K->64K(4032K), 0.0823952 secs] 3968K->2023K(32704K),0.0827626 secs]
  3. Total time for which application threads were stopped:0.0839428 seconds
  4. Application time: 0.9871271 seconds
  5. [GC [DefNew: 4020K->64K(4032K), 0.0412448 secs] 5979K->2374K(32704K),0.0415248 secs]
  6. Total time for which application threads were stopped:0.0464380 seconds

[java] view plaincopy

  1. Application time: 0.5114944 seconds 
  2. [GC [DefNew: 3968K->64K(4032K), 0.0823952 secs] 3968K->2023K(32704K), 0.0827626 secs] 
  3. Total time for which application threads were stopped: 0.0839428 seconds 
  4. Application time: 0.9871271 seconds 
  5. [GC [DefNew: 4020K->64K(4032K), 0.0412448 secs] 5979K->2374K(32704K), 0.0415248 secs] 
  6. Total time for which application threads were stopped: 0.0464380 seconds 

  1. Application time: 0.5114944 seconds

  2. [GC [DefNew: 3968K->64K(4032K), 0.0823952 secs] 3968K->2023K(32704K), 0.0827626 secs]

  3. Total time for which application threads were stopped: 0.0839428 seconds

  4. Application time: 0.9871271 seconds

  5. [GC [DefNew: 4020K->64K(4032K), 0.0412448 secs] 5979K->2374K(32704K), 0.0415248 secs]

  6. Total time for which application threads were stopped: 0.0464380 seconds

Young Generation 的Minor收集占用的時間可以計算如下：

應用線程被中斷的總時常/（應用執行總時?L+應用線程被中斷的總時常），那麼在本例中垃圾收集占用的時?L約為系統的5％~14％。那麼當垃圾收集占用的時間的比例越大的時候，系統的響應将越慢。

提示：對于網際網路應用系統的響應稍微慢一些，使用者是可以接受的，但是對于GUI類型的應用響應速度慢将會給使用者帶來非常不好的體驗。

例4：如何決定Tenured Generation 的大小

分别以-Xmn8m -Xmx32m和-Xmn8m -Xmx64m進行對比，先執行

[java] view plaincopy

  1. java -verbose:gc -Xmn8m -Xmx32m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java類

[java] view plaincopy

  1. java -verbose:gc -Xmn8m -Xmx32m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java類  
java -verbose:gc -Xmn8m -Xmx32m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java類

指令行将提示（隻提取了Major收集）

[java] view plaincopy

  1. 111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K),0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K),0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]
  2. 122.463: [GC 122.463: [DefNew: 8128K->8128K(8128K),0.0000560 secs]122.463: [Tenured: 18630K->2366K(24576K),0.1322560 secs] 26758K->2366K(32704K), 0.1325284 secs]
  3. 133.896: [GC 133.897: [DefNew: 8128K->8128K(8128K), 0.0000443 secs]133.897: [Tenured: 18240K->2573K(24576K),0.1340199secs] 26368K->2573K(32704K), 0.1343218 secs]
  4. 144.112: [GC 144.112: [DefNew: 8128K->8128K(8128K),0.0000544 secs]144.112: [Tenured: 16564K->2304K(24576K),0.1246831 secs] 24692K->2304K(32704K), 0.1249602 secs]

[java] view plaincopy

  1. 111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354secs] 26282K->2311K(32704K), 0.1293306 secs] 
  2. 122.463: [GC 122.463: [DefNew: 8128K->8128K(8128K), 0.0000560 secs]122.463: [Tenured: 18630K->2366K(24576K), 0.1322560secs] 26758K->2366K(32704K), 0.1325284 secs] 
  3. 133.896: [GC 133.897: [DefNew: 8128K->8128K(8128K), 0.0000443 secs]133.897: [Tenured: 18240K->2573K(24576K), 0.1340199secs] 26368K->2573K(32704K), 0.1343218 secs] 
  4. 144.112: [GC 144.112: [DefNew: 8128K->8128K(8128K), 0.0000544 secs]144.112: [Tenured: 16564K->2304K(24576K), 0.1246831secs] 24692K->2304K(32704K), 0.1249602 secs] 

  1. 111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

  2. 122.463: [GC 122.463: [DefNew: 8128K->8128K(8128K), 0.0000560 secs]122.463: [Tenured: 18630K->2366K(24576K), 0.1322560 secs] 26758K->2366K(32704K), 0.1325284 secs]

  3. 133.896: [GC 133.897: [DefNew: 8128K->8128K(8128K), 0.0000443 secs]133.897: [Tenured: 18240K->2573K(24576K), 0.1340199 secs] 26368K->2573K(32704K), 0.1343218 secs]

  4. 144.112: [GC 144.112: [DefNew: 8128K->8128K(8128K), 0.0000544 secs]144.112: [Tenured: 16564K->2304K(24576K), 0.1246831 secs] 24692K->2304K(32704K), 0.1249602 secs]

再執行

[java] view plaincopy

  1. java -verbose:gc -Xmn8m -Xmx64m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java類

[java] view plaincopy

  1. java -verbose:gc -Xmn8m -Xmx64m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java類  
java -verbose:gc -Xmn8m -Xmx64m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java類

指令行将提示（隻提取了Major收集）

[java] view plaincopy

  1. 90.597: [GC 90.597: [DefNew: 8128K->8128K(8128K),0.0000542 secs]90.597: [Tenured: 49841K->5141K(57344K),0.2129882 secs] 57969K->5141K(65472K), 0.2133274 secs]
  2. 120.899: [GC 120.899: [DefNew: 8128K->8128K(8128K),0.0000550 secs]120.899: [Tenured: 50384K->2430K(57344K),0.2216590 secs] 58512K->2430K(65472K), 0.2219384 secs]
  3. 153.968: [GC 153.968: [DefNew: 8128K->8128K(8128K), 0.0000511 secs]153.968: [Tenured: 51164K->2309K(57344K),0.2193906secs] 59292K->2309K(65472K), 0.2196372 secs]

[java] view plaincopy

  1. 90.597: [GC 90.597: [DefNew: 8128K->8128K(8128K), 0.0000542 secs]90.597: [Tenured: 49841K->5141K(57344K), 0.2129882 secs] 57969K->5141K(65472K), 0.2133274 secs] 
  2. 120.899: [GC 120.899: [DefNew: 8128K->8128K(8128K), 0.0000550 secs]120.899: [Tenured: 50384K->2430K(57344K), 0.2216590secs] 58512K->2430K(65472K), 0.2219384 secs] 
  3. 153.968: [GC 153.968: [DefNew: 8128K->8128K(8128K), 0.0000511 secs]153.968: [Tenured: 51164K->2309K(57344K), 0.2193906secs] 59292K->2309K(65472K), 0.2196372 secs] 

  1. 90.597: [GC 90.597: [DefNew: 8128K->8128K(8128K), 0.0000542 secs]90.597: [Tenured: 49841K->5141K(57344K), 0.2129882 secs] 57969K->5141K(65472K), 0.2133274 secs]

  2. 120.899: [GC 120.899: [DefNew: 8128K->8128K(8128K), 0.0000550 secs]120.899: [Tenured: 50384K->2430K(57344K), 0.2216590 secs] 58512K->2430K(65472K), 0.2219384 secs]

  3. 153.968: [GC 153.968: [DefNew: 8128K->8128K(8128K), 0.0000511 secs]153.968: [Tenured: 51164K->2309K(57344K), 0.2193906 secs] 59292K->2309K(65472K), 0.2196372 secs]

可以看出在Heap size 為32m的時候系統等候時間約為0.13秒左右，而設定為64m的時候等候時間則增大到0.22秒左右了。但是在32m的時候系統的Major收集間隔為 10秒左右，而Heap size 增加到64m的時候為30秒。那麼應用在運作的時候是選擇32m還是64m呢？如果應用是web類型（即要求有大的吞吐量）的應用則使用64m（即 heapsize大一些）的比較好。對于要求實時響應要求較高的場合（例如GUI型的應用）則使用32m比較好一些。

注意：

1。因為在JVM5運作時已經對Heap-size進行了優化，是以在能确定java應用運作時不會超過預設的Heap size的情況下建議不要對這些值進行修改。

2。 Heap size的 -Xms -Xmn 設定不要超出實體記憶體的大小。否則會提示“Error occurred during initialization of VM Could not reserve enough space for object heap”。

例5:如何縮短minor收集的時間

下面比較一下采用-XX:+UseParNewGC選項和不采用它的時候的minor收集将有什麼不同。先執行

[java] view plaincopy

  1. java -jar -server -verbose:gc -Xmn8m -Xms32m -Xmx32m SwingSet2.jar

[java] view plaincopy

  1. java -jar -server -verbose:gc -Xmn8m -Xms32m -Xmx32m SwingSet2.jar   
java -jar -server -verbose:gc -Xmn8m -Xms32m -Xmx32m SwingSet2.jar

系統将輸出如下資訊（片段〕

[java] view plaincopy

  1. [GC 7807K->2641K(32576K), 0.0676654 secs]
  2. [GC 10436K->3108K(32576K), 0.0245328 secs]
  3. [GC 10913K->3176K(32576K), 0.0072865 secs]
  4. [GC 10905K->4097K(32576K), 0.0223928 secs]

[java] view plaincopy

  1. [GC 7807K->2641K(32576K), 0.0676654 secs] 
  2. [GC 10436K->3108K(32576K), 0.0245328 secs] 
  3. [GC 10913K->3176K(32576K), 0.0072865 secs] 
  4. [GC 10905K->4097K(32576K), 0.0223928 secs] 

  1. [GC 7807K->2641K(32576K), 0.0676654 secs]

  2. [GC 10436K->3108K(32576K), 0.0245328 secs]

  3. [GC 10913K->3176K(32576K), 0.0072865 secs]

  4. [GC 10905K->4097K(32576K), 0.0223928 secs]

之後再執行

[java] view plaincopy

  1. java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar

[java] view plaincopy

  1. java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar  
java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar

系統将輸出如下資訊（片段〕

[java] view plaincopy

  1. [ParNew 7808K->2656K(32576K), 0.0447687 secs]
  2. [ParNew 10441K->3143K(32576K), 0.0179422 secs]
  3. [ParNew 10951K->3177K(32576K), 0.0031914 secs]
  4. [ParNew 10985K->3867K(32576K), 0.0154991 secs]

[java] view plaincopy

  1. [ParNew 7808K->2656K(32576K), 0.0447687 secs] 
  2. [ParNew 10441K->3143K(32576K), 0.0179422 secs] 
  3. [ParNew 10951K->3177K(32576K), 0.0031914 secs] 
  4. [ParNew 10985K->3867K(32576K), 0.0154991 secs] 

  1. [ParNew 7808K->2656K(32576K), 0.0447687 secs]

  2. [ParNew 10441K->3143K(32576K), 0.0179422 secs]

  3. [ParNew 10951K->3177K(32576K), 0.0031914 secs]

  4. [ParNew 10985K->3867K(32576K), 0.0154991 secs]

很顯然使用了-XX:+UseParNewGC選項的minor收集的時間要比不使用的時候優。

例6:如何縮短major收集的時間

下面比較一下采用-XX:+UseConcMarkSweepGC選項和不采用它的時候的major收集将有什麼不同。先執行

[java] view plaincopy

  1. java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar

[java] view plaincopy

  1. java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar  
java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar

系統将輸出如下資訊（片段〕

[java] view plaincopy

  1. [Full GC 22972K->18690K(262080K), 0.2326676 secs]
  2. [Full GC 18690K->18690K(262080K), 0.1701866 secs

[java] view plaincopy

  1. [Full GC 22972K->18690K(262080K), 0.2326676 secs] 
  2. [Full GC 18690K->18690K(262080K), 0.1701866 secs 

  1. [Full GC 22972K->18690K(262080K), 0.2326676 secs]

  2. [Full GC 18690K->18690K(262080K), 0.1701866 secs

之後再執行

[html] view plaincopy

  1. java -jar -verbose:gc -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar

[html] view plaincopy

  1. java -jar -verbose:gc -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar  
java -jar -verbose:gc -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar

系統将輸出如下資訊（片段〕

[java] view plaincopy

  1. [Full GC 56048K->18869K(260224K), 0.3104852 secs]

[java] view plaincopy

  1. [Full GC 56048K->18869K(260224K), 0.3104852 secs]  
[Full GC 56048K->18869K(260224K), 0.3104852 secs]

提示：此選項在Heap Size 比較大而且Major收集時間較長的情況下使用更合适。

例7:關于-server選項

在JVM中将運作中的類認定為server-class的時候使用此選項。SUN 的Hot Spot JVM5 如果判斷到系統的配置滿足如下條件則自動将運作的類認定為server-class，并且會自動設定jvm的選項（當沒有手工設定這選項的時候〕而且 HOTSPOT JVM5提供了自動調優的功能，他會根據JVM的運作情況進行調整。如果沒有特别的需要是不需要太多的人工幹預的。SUN形象的稱這個機制為“人體工學 ”（Ergonomics〕。具體可以參考http://java.sun.com/docs/hotspot/gc5.0/ergo5.html

*.具有2個或更多個實體的處理器

*.具有2G或者更多的實體記憶體

提示：此選項要放在所有選項的前面。例如：java -server 其他選項 java類

java jvm gc
上一篇: 779. 最長公共字元串字尾
下一篇: Day45SpringBoot整合Jquery

繼續閱讀