java heap space解決方法和JVM參數設置


    在JVM中如果98%的時間是用於GC(Garbage Collection)且可用的 Heap size 不足2%的時候將拋出異常信息,java.lang.OutOfMemoryError: Java heap space。 
所以產生這個異樣的原因通常有兩種:
 1.程序中出現了死循環
 2.程序占用內存太多,超過了JVM堆設置的最大值。  對於第一種情況,需要自己查看程序代碼,這里不再多說。  第二種情況,我們手工擴大JVM堆的參數設置。JVM堆的設置是指java程序運行過程中JVM可以調配使用的內存空間的設置。在JVM啟動時,JVM堆會自動設置heap size值。通常情況下,初始空間(即-Xms)默認值是物理內存的1/64,最大空間是物理內存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項可進行設置。這里對各個參數的意義解釋一下: -Xms:初始值  -Xmx:最大值  -Xmn:最小值  Heap Size的設置不宜太小,也不宜太大。若設置太小程序的響應速度會變慢了,因為GC占用了更多的時間,而應用分配到的執行時間較少。太大也會造成空間的浪費,而且也會影響其他程序的正常運行。Heap Size 最大最好不要超過可用物理內存的80%。建議將-Xms和-Xmx選項設置為相同,而-Xmn為1/4的-Xmx值。 設置的方法主要有以下幾個: 
 1.就是在執行JAVA類文件時加上這個參數,其中className是需要執行的確類名。(包括包名)如:java -Xms32m -Xmx800m className 這個不僅解決問題了,而且執行的速度比沒有設置的時候快很多。如果是開發測試,也可以再eclipse中直接設置。Eclipse ->run -arguments 中的VM arguments 中輸入-Xms32m -Xmx800m這個參數就可以了。 
 2.可以在windows更改系統環境變量加上JAVA_OPTS=-Xms64m -Xmx512m。  3.如果用的tomcat,在windows下,可以在C:\tomcat5.5.9\bin\catalina.bat(具體路徑根據自己tomcat的位置而定) 中加上:set JAVA_OPTS=-Xms64m -Xmx256m (大小依自己內存而定)位置在: rem Guess CATALINA_HOME if not defined 這行的下面加合適.   4.如果是linux系統Linux 在{tomcat_home}/bin/catalina.sh的前面,加 set JAVA_OPTS='-Xms64 -Xmx512'

因為程序要從數據讀取近10W行記錄處理,當讀到9W的時候就出現 java.lang.OutOfMemoryError: Java heap space 這樣的錯誤。
在網上一查可能是JAVA的堆棧設置太小的原因。
跟據網上的答案大致有這兩種解決方法:
1、設置環境變量
set JAVA_OPTS= -Xms32m -Xmx512m
可以根據自己機器的內存進行更改,但本人測試這種方法並沒有解決問題。可能是還有哪里需要設置。

2、java -Xms32m -Xmx800m className
就是在執行JAVA類文件時加上這個參數,其中className是需要執行的確類名。(包括包名)
這個解決問題了。而且執行的速度比沒有設置的時候快很多。

如果在測試的時候可能會用Eclispe 這時候就需要在Eclipse ->run -arguments 中的VM arguments 中輸入-Xms32m -Xmx800m這個參數就可以了。


java.lang.OutOfMemoryError: Java heap space
===================================================

使用Java程序從數據庫中查詢大量的數據時出現異常:
java.lang.OutOfMemoryError: Java heap space


在JVM中如果98%的時間是用於GC且可用的 Heap size 不足2%的時候將拋出此異常信息。

JVM堆的設置是指java程序運行過程中JVM可以調配使用的內存空間的設置.

JVM在啟動的時候會自動設置Heap size的值,其初始空間(即-Xms)是物理內存的1/64,最大空間(-Xmx)是物理內存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項可進行設置。
例如:java -jar -Xmn16m -Xms64m -Xmx128m MyApp.jar

如果Heap Size設置偏小,除了這些異常信息外,還會發現程序的響應速度變慢了。GC占用了更多的時間,而應用分配到的執行時間較少。

Heap Size 最大不要超過可用物理內存的80%,一般的要將-Xms和-Xmx選項設置為相同,而-Xmn為1/4的-Xmx值。
Heap size的 -Xms -Xmn 設置不要超出物理內存的大小。否則會提示“Error occurred during initialization of VM Could not reserve enough space for object heap”。

==========================================================
經過一個晚上的努力終於完成了一個文件替換指定字符串的程序,但是由於我要替換的全站程序html文件太多,所以eclipse下邊老是在一個目錄結束后 報出java.lang.OutOfMemoryError: Java heap space的異常,然后就崩潰了。

我一想肯定是頻繁操作造成來不及回收,於是在每個循環之后加上一個Thread.sleep(1000),發現還是到那個目錄下就死掉,於是把 1000改成5000,還是到那里死掉,我想可能不是來不及回收這么簡單,或許sun 的JVM里邊剛好對於這種情況不釋放也有可能。
接着我又把啟動的參數添上一個 -Xmx256M,這回就可以了。

想一想,還是對於垃圾回收的原理不太了解,就在網上查了一下,發現了幾篇不錯的文章。

http://java.ccidnet.com/art/3539/20060314/476073_1.html
http://www.pconline.com.cn/pcedu/empolder/gj/java/0509/701281.html


還有:Java堆的管理—垃圾回收提到一下幾點,很不錯,或許可以作為寫程序時候的准則:

  (1)不要試圖去假定垃圾收集發生的時間,這一切都是未知的。比如,方法中的一個臨時對象在方法調用完畢后就變成了無用對象,這個時候它的內存 就可以被釋放。

  (2)Java中提供了一些和垃圾收集打交道的類,而且提供了一種強行執行垃圾收集的方法--調用System.gc(),但這同樣是個不確定 的方法。Java 中並不保證每次調用該方法就一定能夠啟動垃圾收集,它只不過會向JVM發出這樣一個申請,到底是否真正執行垃圾收集,一切都是個未知數。

  (3)挑選適合自己的垃圾收集器。一般來說,如果系統沒有特殊和苛刻的性能要求,可以采用JVM的缺省選項。否則可以考慮使用有針對性的垃圾收 集器,比如增量收集器就比較適合實時性要求較高的系統之中。系統具有較高的配置,有比較多的閑置資源,可以考慮使用並行標記/清除收集器。

  (4)關鍵的也是難把握的問題是內存泄漏。良好的編程習慣和嚴謹的編程態度永遠是最重要的,不要讓自己的一個小錯誤導致內存出現大漏洞。

  (5)盡早釋放無用對象的引用。
大多數程序員在使用臨時變量的時候,都是讓引用變量在退出活動域(scope)后,自動設置為null,暗示垃圾收集器來收集該對象,還必須注意該引用的 對象是否被監聽,如果有,則要去掉監聽器,然后再賦空值。

就是說,對於頻繁申請內存和釋放內存的操作,還是自己控制一下比較好,但是System.gc()的方法不一定適用,最好使用finallize強 制執行或者寫自己的finallize方法。

================================================
tomcat


遇到TOMCAT出錯:java.lang.OutOfMemoryError: Java heap space,於是查了資料,找到了解決方法:
If Java runs out of memory, the following error occurs:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
Java heap size can be increased as follows:

java -Xms -Xmx
Defaults are:
java -Xms32m -Xmx128m

如果你用win
/tomcat/bin/catalina.bat 加上下面的命令:
set JAVA_OPTS=-Xms32m -Xmx256m

如果你用unix/linux
/tomcat/bin/catalina.sh 加上下面的命令:
JAVA_OPTS="-Xms32m -Xmx256m"

業界有很多強大的java profile的工具,比如Jporfiler,yourkit,這些收費的東西我就不想說了,想說的是,其實java自己就提供了很多內存監控的小工具,下面列舉的工具只是一小部分,仔細研究下jdk的工具,還是蠻有意思的呢:)

   

1:gc日志輸出

       在jvm啟動參數中加入 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimestamps -XX:+PrintGCApplicationStopedTime,jvm將會按照這些參數順序輸出gc概要信息,詳細信息,gc時間信息,gc造成 的應用暫停時間。如果在剛才的參數后面加入參數 -Xloggc:文件路徑,gc信息將會輸出到指定的文件中。其他參數還有

-verbose:gc和-XX:+PrintTenuringDistribution等。


2:jconsole

      jconsole是jdk自帶的一個內存分析工具,它提供了圖形界面。可以查看到被監控的jvm的內存信息,線程信息,類加載信息,MBean信息。

      jconsole位於jdk目錄下的bin目錄,在windows下是jconsole.exe,在unix和linux下是 jconsole.sh,jconsole可以監控本地應用,也可以監控遠程應用。 要監控本地應用,執行jconsole pid,pid就是運行的java進程id,如果不帶上pid參數,則執行jconsole命令后,會看到一個對話框彈出,上面列出了本地的java進 程,可以選擇一個進行監控。如果要遠程監控,則要在遠程服務器的jvm參數里加入一些東西,因為jconsole的遠程監控基於jmx的,關於 jconsole詳細用法,請見專門介紹jconsle的文章,我也會在博客里專門詳細介紹jconsole。


3:jviusalvm

      在JDK6 update 7之后,jdk推出了另外一個工具:jvisualvm,java可視化虛擬機,它不但提供了jconsole類似的功能,還提供了jvm內存和cpu實時診斷,還有手動dump出jvm內存情況,手動執行gc。

     和jconsole一樣,運行jviusalvm,在jdk的bin目錄下執行jviusalvm,windows下是jviusalvm.exe,linux和unix下是jviusalvm.sh。


4:jmap

    jmap是jdk自帶的jvm內存分析的工具,位於jdk的bin目錄。jdk1.6中jmap命令用法:

Html代碼   收藏代碼
  1. Usage:  
  2. jmap -histo <pid> (to connect to running process and print histogram of java object heap   
  3. jmap -dump:<dump-options<pid>  (to connect to running process and dump java heap)  
  4. dump-options: format=b binary default file=<file>   
  5. dump heap to <file>    
  6. Example: jmap -dump:format=b,file=heap.bin <pid>   

 

    jmap -histo <pid>在屏幕上顯示出指定pid的jvm內存狀況。以我本機為例,執行該命令,屏幕顯示:

Html代碼   收藏代碼
  1. 1:         24206        2791864  constMethodKlass >    
  2. 2:         22371        2145216  [C   
  3. 3:         24206        1940648  methodKlass >    
  4. 4:          1951        1364496  constantPoolKlass >    
  5. 5:         26543        1282560  symbolKlass >    
  6. 6:          6377        1081744  [B   
  7. 7:          1793         909688  constantPoolCacheKlass >    
  8. 8:          1471         614624  instanceKlassKlass >    
  9. 9:         14581         548336  [Ljava.lang.Object;   
  10. 10:          3863         513640  [I   
  11. 11:         20677         496248  java.lang.String      
  12. 12:          3621         312776  [Ljava.util.HashMap$Entry;   
  13. 13:          3335         266800  java.lang.reflect.Method   
  14. 14:          8256         264192  java.io.ObjectStreamClass$WeakClassKey   
  15. 15:          7066         226112  java.util.TreeMap$Entry   
  16. 16:          2355         173304  [S   
  17. 17:          1687         161952  java.lang.Class   
  18. 18:          2769         150112  [[I   
  19. 19:          3563         142520  java.util.HashMap   
  20. 20:          5562         133488  java.util.HashMap$Entry   
  21. Total        239019       17140408   

  為了方便查看,我刪掉了一些行。從上面的信息很容易看出,#instance指的是對象數量,#bytes指的是這些對象占用的內存大小,class name指的是對象類型。

     再看jmap的dump選項,這個選項是將jvm的堆中內存信息輸出到一個文件中,在我本機執行

jmap -dump:file=c:\dump.txt 340  

注意340是我本機的java進程pid,dump出來的文件比較 大有10幾M,而且我只是開了tomcat,跑了一個很簡單的應用,且沒有任何訪問,可以想象,大型繁忙的服務器上,dump出來的文件該有多大。需要知 道的是,dump出來的文件信息是很原始的,絕不適合人直接觀看,而jmap -histo顯示的內容又太簡單,例如只顯示某些類型的對象占用多大內存,以及這些對象的數量,但是沒有更詳細的信息,例如這些對象分別是由誰創建的。那 這么說,dump出來的文件有什么用呢?當然有用,因為有專門分析jvm的內存dump文件的工具。


5:jhat

    上面說了,有很多工具都能分析jvm的內存dump文件,jhat就是sun jdk6及以上版本自帶的工具,位於jdk的bin目錄,執行 jhat -J -Xmx512m [file] ,file就是dump文件路徑。jhat內置一個簡單的web服務器,此命令執行后,jhat在命令行里顯示分析結果的訪問地址,可以用 -port選項指定端口,具體用法可以執行jhat -heap查看幫助信息。訪問指定地址后,就能看到頁面上顯示的信息,比jmap -histo命令顯示的豐富得多,更為詳細。


6:eclipse內存分析器

    上面說了jhat,它能分析jvm的dump文件,但是全部是文字顯示,eclipse memory analyzer,是一個eclipse提供用於分析jvm 堆dump的插件,網址為 http://www.eclipse.org/mat ,它的分析速度比jhat快,分析結果是圖形界面顯示,比jhat的可讀性更高。其實jvisualvm也可以分析dump文件,也是有圖形界面顯示的。


7:jstat

      如果說jmap傾向於分析jvm內存中對象信息的話,那么jsta就是傾向於分析jvm內存的gc情況。都是jvm內存分析工具,但顯然,它們是從不同維 度來分析的。jsat常用的參數有很多,如 -gc,-gcutil,-gccause,這些選項具體作用可查看jsat幫助信息,我經常用-gcutil,這個參數的作用不斷的顯示當前指定的 jvm內存的垃圾收集的信息。

      我在本機執行 jstat -gcutil 340 10000,這個命令是每個10秒鍾輸出一次jvm的gc信息,10000指的是間隔時間為10000毫秒。屏幕上顯示如下信息(我只取了第一行,因為是 按的一定頻率顯示,所以實際執行的時候,會有很多行):

  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT  
 54.62   0.00  42.87  43.52  86.24   1792    5.093    33    7.670   12.763

        額。。。怎么說呢,要看懂這些信息代表什么意思,還必須對jvm的gc機制有一定的了解才行啊。其實如果對sun的 hot spot jvm的gc比較了解的人,應該很容易看懂這些信息,但是不清楚gc機制的人,有點莫名其妙,所以在這里我還是先講講sun的jvm的gc機制吧。說到 gc,其實不僅僅只是java的概念,其實在java之前,就有很多語言有gc的概念了,gc嘛就是垃圾收集的意思,更多的是一種算法性的東西,而跟具體 語言沒太大關系,所以關於gc的歷史,gc的主流算法我就不講了,那扯得太遠了,扯得太遠了就是扯淡。sun現在的jvm,內存的管理模型是分代模型,所 以gc當然是分代收集了。分代是什么意思呢?就是將對象按照生命周期分成三個層次,分別是:新生代,舊生代,持久代。對象剛開始分配的時候,大部分都在新 生代,當新生代gc提交被觸發后了,執行一次新生代范圍內的gc,這叫minor gc,如果執行了幾次minor gc后,還有對象存活,將這些對象轉入舊生代,因為這些對象已經經過了組織的重重考驗了哇。舊生代的gc頻率會更低一些,如果舊生代執行了gc,那就是 full gc,因為不是局部gc,而是全內存范圍的gc,這會造成應用停頓,因為全內存收集,必須封鎖內存,不許有新的對象分配到內存,持久代就是一些jvm期 間,基本不會消失的對象,例如class的定義,jvm方法區信息,例如靜態塊。需要主要的是,新生代里又分了三個空 間:eden,susvivor0,susvivor1,按字面上來理解,就是伊甸園區,幸存1區,幸存2區。新對象分配在eden區中,eden區滿 時,采用標記-復制算法,即檢查出eden區存活 的對象,並將這些對象復制到是s0或s1中,然后清空eden區。jvm的gc說開來,不只是這么簡單,例如還有串行收集,並行收集,並發收集,還有著名 的火車算法,不過那說得太遠了,現在對這個有大致了解就好。說到這里,再來看一下上面輸出的信息:

   S0       S1       E        O          P       YGC     YGCT    FGC    FGCT     GCT  
 54.62   0.00  42.87  43.52  86.24   1792    5.093    33    7.670   12.763

S0:新生代的susvivor0區,空間使用率為54..62%

S1:新生代的susvivor1區,空間使用率為0.00%(因為還沒有執行第二次minor收集)

E:eden區,空間使用率42.87%

O:舊生代,空間使用率43.52%

P:持久帶,空間使用率86.24%

YGC:minor gc執行次數1792次

YGCT:minor gc耗費的時間5.093毫秒

FGC:full gc執行次數33

FGCT:full gc耗費的時間7.670毫秒

GCT:gc耗費的總時間12.763毫秒


 怎樣選擇工具

     上面列舉的一些工具,各有利弊,其實如果在開發環境,使用什么樣的工具是無所謂的,只要能得到結果就好。但是在生產環境里,卻不能亂選擇,因為這些工具本 身就會耗費大量的系統資源,如果在一個生產服務器壓力很大的時候,貿然執行這些工具,可能會造成很意外的情況。最好不要在服務器本機監控,遠程監控會比較 好一些,但是如果要遠程監控,服務器端的啟動腳本要加入一些jvm參數,例如用jconsloe遠程監控tomcat或jboss等,都需要設置jvm的 jmx參數,如果僅僅只是分析服務器的內存分配和gc信息,強烈推薦,先用jmap導出服務器端的jvm的堆dump文件,然后再用jhat,或者 jvisualvm,或者eclipse內存分析器來分析內存狀況。

打賞

免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2022 CODEPRJ.COM