在JVM中如果98%的時間是用于GC(Garbage Collection)且可用的 Heap size 不足2%的時候?qū)伋霎惓Ｐ畔?，java.lang.OutOfMemoryError: Java heap space。 

所以產(chǎn)生這個異樣的原因通常有兩種：

1.程序中出現(xiàn)了死循環(huán)

2.程序占用內(nèi)存太多，超過了JVM堆設(shè)置的最大值。

    對于第一種情況，需要自己查看程序代碼，這里不再多說。

    第二種情況，我們手工擴大JVM堆的參數(shù)設(shè)置。JVM堆的設(shè)置是指java程序運行過程中JVM可以調(diào)配使用的內(nèi)存空間的設(shè)置。在JVM啟動時，JVM堆會自動設(shè)置heap size值。通常情況下，初始空間（即-Xms）默認(rèn)值是物理內(nèi)存的1/64，最大空間是物理內(nèi)存的1/4?？梢岳?/p>

用JVM提供的-Xmn -Xms -Xmx等選項可進行設(shè)置。這里對各個參數(shù)的意義解釋一下：

-Xms：初始值 

-Xmx：最大值 

-Xmn：最小值 

Heap Size的設(shè)置不宜太小，也不宜太大。若設(shè)置太小程序的響應(yīng)速度會變慢了，因為GC占用了更多的時間，而應(yīng)用分配到的執(zhí)行時間較少。太大也會造成空間的浪費，而且也會影響其他程序的正常運行。Heap Size 最大最好不要超過可用物理內(nèi)存的80％。建議將-Xms和

-Xmx選項設(shè)置為相同，而-Xmn為1/4的-Xmx值。

設(shè)置的方法主要有以下幾個： 

1.就是在執(zhí)行JAVA類文件時加上這個參數(shù)，其中className是需要執(zhí)行的確類名。（包括包名）如：java -Xms32m -Xmx800m className 這個不僅解決問題了，而且執(zhí)行的速度比沒有設(shè)置的時候快很多。如果是開發(fā)測試，也可以再eclipse中直接設(shè)置。Eclipse 

->run -arguments 中的VM arguments 中輸入-Xms32m -Xmx800m這個參數(shù)就可以了。 

2.可以在windows更改系統(tǒng)環(huán)境變量加上JAVA_OPTS=-Xms64m -Xmx512m。

3.如果用的tomcat,在windows下,可以在C:tomcat5.5.9bincatalina.bat（具體路徑根據(jù)自己tomcat的位置而定） 中加上:set JAVA_OPTS=-Xms64m -Xmx256m （大小依自己內(nèi)存而定）位置在: rem Guess CATALINA_HOME if not defined 這行的下面加合適. 

4.如果是linux系統(tǒng)Linux 在{tomcat_home}/bin/catalina.sh的前面，加 set JAVA_OPTS='-Xms64 -Xmx512'

因為程序要從數(shù)據(jù)讀取近10W行記錄處理，當(dāng)讀到9W的時候就出現(xiàn) java.lang.OutOfMemoryError: Java heap space 這樣的錯誤。

 在網(wǎng)上一查可能是JAVA的堆棧設(shè)置太小的原因。

 跟據(jù)網(wǎng)上的答案大致有這兩種解決方法：

1、設(shè)置環(huán)境變量

set JAVA_OPTS= -Xms32m -Xmx512m

可以根據(jù)自己機器的內(nèi)存進行更改,但本人測試這種方法并沒有解決問題?？赡苁沁€有哪里需要設(shè)置。

2、java -Xms32m -Xmx800m className

就是在執(zhí)行JAVA類文件時加上這個參數(shù)，其中className是需要執(zhí)行的確類名。（包括包名）

 這個解決問題了。而且執(zhí)行的速度比沒有設(shè)置的時候快很多。

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

java.lang.OutOfMemoryError: Java heap space 

 ===================================================

使用Java程序從數(shù)據(jù)庫中查詢大量的數(shù)據(jù)時出現(xiàn)異常:

java.lang.OutOfMemoryError: Java heap space

在JVM中如果98％的時間是用于GC且可用的 Heap size 不足2％的時候?qū)伋龃水惓Ｐ畔ⅰ?/p>

JVM堆的設(shè)置是指java程序運行過程中JVM可以調(diào)配使用的內(nèi)存空間的設(shè)置.

JVM在啟動的時候會自動設(shè)置Heap size的值，其初始空間(即-Xms)是物理內(nèi)存的1/64，最大空間(-Xmx)是物理內(nèi)存的1/4?？梢岳肑VM提供的-Xmn -Xms -Xmx等選項可進行設(shè)置。

 例如：java -jar -Xmn16m -Xms64m -Xmx128m MyApp.jar

如果Heap Size設(shè)置偏小，除了這些異常信息外，還會發(fā)現(xiàn)程序的響應(yīng)速度變慢了。GC占用了更多的時間，而應(yīng)用分配到的執(zhí)行時間較少。

Heap Size 最大不要超過可用物理內(nèi)存的80％，一般的要將-Xms和-Xmx選項設(shè)置為相同，而-Xmn為1/4的-Xmx值。

Heap size的 -Xms -Xmn 設(shè)置不要超出物理內(nèi)存的大小。否則會提示“Error occurred during initialization of VM Could not reserve enough space for object heap”。

==========================================================

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

我一想肯定是頻繁操作造成來不及回收，于是在每個循環(huán)之后加上一個Thread.sleep（1000）,發(fā)現(xiàn)還是到那個目錄下就死掉，于是把 1000改成5000，還是到那里死掉，我想可能不是來不及回收這么簡單，或許sun 的JVM里邊剛好對于這種情況不釋放也有可能。

 接著我又把啟動的參數(shù)添上一個 -Xmx256M,這回就可以了。

想一想，還是對于垃圾回收的原理不太了解，就在網(wǎng)上查了一下，發(fā)現(xiàn)了幾篇不錯的文章。

http://java.ccidnet.com/art/3539/20060314/476073_1.html

http://www.pconline.com.cn/pcedu/empolder/gj/java/0509/701281.html

還有:Java堆的管理—垃圾回收提到一下幾點，很不錯，或許可以作為寫程序時候的準(zhǔn)則：

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

　?。?）Java中提供了一些和垃圾收集打交道的類，而且提供了一種強行執(zhí)行垃圾收集的方法--調(diào)用System.gc()，但這同樣是個不確定 的方法。Java 中并不保證每次調(diào)用該方法就一定能夠啟動垃圾收集，它只不過會向JVM發(fā)出這樣一個申請，到底是否真正執(zhí)行垃圾收

集，一切都是個未知數(shù)。

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

慮使用并行標(biāo)記/清除收集器。

　　（4）關(guān)鍵的也是難把握的問題是內(nèi)存泄漏。良好的編程習(xí)慣和嚴(yán)謹(jǐn)?shù)木幊虘B(tài)度永遠(yuǎn)是最重要的，不要讓自己的一個小錯誤導(dǎo)致內(nèi)存出現(xiàn)大漏洞。

　?。?）盡早釋放無用對象的引用。

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

就是說,對于頻繁申請內(nèi)存和釋放內(nèi)存的操作,還是自己控制一下比較好,但是System.gc()的方法不一定適用，最好使用finallize強 制執(zhí)行或者寫自己的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"

 jvm 內(nèi)存查看與分析工具  

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

1：gc日志輸出   

       在jvm啟動參數(shù)中加入 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimestamps -XX:+PrintGCApplicationStopedTime，jvm將會按照這些參數(shù)順序輸出gc概要信息，詳細(xì)信息，gc時間信息，gc造成 的應(yīng)用暫停時間。如果在剛才的參數(shù)后面加入?yún)?shù) -

Xloggc:文件路徑，gc信息將會輸出到指定的文件中。其他參數(shù)還有 

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

2：jconsole  

      jconsole是jdk自帶的一個內(nèi)存分析工具，它提供了圖形界面?？梢圆榭吹奖槐O(jiān)控的jvm的內(nèi)存信息，線程信息，類加載信息，MBean信息。 

      jconsole位于jdk目錄下的bin目錄，在windows下是jconsole.exe，在unix和linux下是 jconsole.sh，jconsole可以監(jiān)控本地應(yīng)用，也可以監(jiān)控遠(yuǎn)程應(yīng)用。 要監(jiān)控本地應(yīng)用，執(zhí)行jconsole pid，pid就是運行的java進程id，如果不帶上pid參數(shù)，則執(zhí)行jconsole命

令后，會看到一個對話框彈出，上面列出了本地的java進 程，可以選擇一個進行監(jiān)控。如果要遠(yuǎn)程監(jiān)控，則要在遠(yuǎn)程服務(wù)器的jvm參數(shù)里加入一些東西，因為jconsole的遠(yuǎn)程監(jiān)控基于jmx的，關(guān)于 jconsole詳細(xì)用法，請見專門介紹jconsle的文章，我也會在博客里專門詳

細(xì)介紹jconsole。 

3:jviusalvm   

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

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

4：jmap   

    jmap是jdk自帶的jvm內(nèi)存分析的工具，位于jdk的bin目錄。jdk1.6中jmap命令用法： 

收藏代碼

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內(nèi)存狀況。以我本機為例，執(zhí)行該命令，屏幕顯示： 

收藏代碼

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指的是對象數(shù)量，#bytes指的是這些對象占用的內(nèi)存大小，class name指的是對象類型。 

     再看jmap的dump選項，這個選項是將jvm的堆中內(nèi)存信息輸出到一個文件中，在我本機執(zhí)行 

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

注意340是我本機的java進程pid，dump出來的文件比較 大有10幾M，而且我只是開了tomcat，跑了一個很簡單的應(yīng)用，且沒有任何訪問，可以想象，大型繁忙的服務(wù)器上，dump出來的文件該有多大。需要知 道的是，dump出來的文件信息是很原始的，絕不適合人直接觀看

，而jmap -histo顯示的內(nèi)容又太簡單，例如只顯示某些類型的對象占用多大內(nèi)存，以及這些對象的數(shù)量，但是沒有更詳細(xì)的信息，例如這些對象分別是由誰創(chuàng)建的。那 這么說，dump出來的文件有什么用呢？當(dāng)然有用，因為有專門分析jvm的內(nèi)存dump文件的工具。 

5：jhat   

    上面說了，有很多工具都能分析jvm的內(nèi)存dump文件，jhat就是sun jdk6及以上版本自帶的工具，位于jdk的bin目錄，執(zhí)行 jhat -J -Xmx512m [file] ，file就是dump文件路徑。jhat內(nèi)置一個簡單的web服務(wù)器，此命令執(zhí)行后，jhat在命令行里顯示分析結(jié)果的訪問地

址，可以用 -port選項指定端口，具體用法可以執(zhí)行jhat -heap查看幫助信息。訪問指定地址后，就能看到頁面上顯示的信息，比jmap -histo命令顯示的豐富得多，更為詳細(xì)。 

6：eclipse內(nèi)存分析器  

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

jvisualvm也可以分析dump文件，也是有圖形界面顯示的。 

7：jstat  

      如果說jmap傾向于分析jvm內(nèi)存中對象信息的話，那么jsta就是傾向于分析jvm內(nèi)存的gc情況。都是jvm內(nèi)存分析工具，但顯然，它們是從不同維 度來分析的。jsat常用的參數(shù)有很多，如 -gc,-gcutil,-gccause，這些選項具體作用可查看jsat幫助信息，我經(jīng)常用-

gcutil，這個參數(shù)的作用不斷的顯示當(dāng)前指定的 jvm內(nèi)存的垃圾收集的信息。 

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

  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比較了解的人，應(yīng)該很容易看懂這些信息，但是不清楚gc機制的人，有點莫名其妙，所以在這里我還是先講講sun的jvm的gc機制

吧。說到 gc，其實不僅僅只是java的概念，其實在java之前，就有很多語言有g(shù)c的概念了，gc嘛就是垃圾收集的意思，更多的是一種算法性的東西，而跟具體 語言沒太大關(guān)系，所以關(guān)于gc的歷史，gc的主流算法我就不講了，那扯得太遠(yuǎn)了，扯得太遠(yuǎn)了就是扯淡。sun現(xiàn)

在的jvm，內(nèi)存的管理模型是分代模型，所 以gc當(dāng)然是分代收集了。分代是什么意思呢？就是將對象按照生命周期分成三個層次，分別是：新生代，舊生代，持久代。對象剛開始分配的時候，大部分都在新 生代，當(dāng)新生代gc提交被觸發(fā)后了，執(zhí)行一次新生代范圍內(nèi)的gc

，這叫minor gc，如果執(zhí)行了幾次minor gc后，還有對象存活，將這些對象轉(zhuǎn)入舊生代，因為這些對象已經(jīng)經(jīng)過了組織的重重考驗了哇。舊生代的gc頻率會更低一些，如果舊生代執(zhí)行了gc，那就是 full gc，因為不是局部gc，而是全內(nèi)存范圍的gc，這會造成應(yīng)用停頓，

因為全內(nèi)存收集，必須封鎖內(nèi)存，不許有新的對象分配到內(nèi)存，持久代就是一些jvm期 間，基本不會消失的對象，例如class的定義，jvm方法區(qū)信息，例如靜態(tài)塊。需要主要的是，新生代里又分了三個空 間：eden，susvivor0，susvivor1，按字面上來理解，就是伊甸園

區(qū)，幸存1區(qū)，幸存2區(qū)。新對象分配在eden區(qū)中，eden區(qū)滿 時，采用標(biāo)記-復(fù)制算法，即檢查出eden區(qū)存活 的對象，并將這些對象復(fù)制到是s0或s1中，然后清空eden區(qū)。jvm的gc說開來，不只是這么簡單，例如還有串行收集，并行收集，并發(fā)收集，還有著名 的火車算法

，不過那說得太遠(yuǎn)了，現(xiàn)在對這個有大致了解就好。說到這里，再來看一下上面輸出的信息： 

   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區(qū)，空間使用率為54..62% 

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

E:eden區(qū)，空間使用率42.87% 

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

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

YGC:minor gc執(zhí)行次數(shù)1792次 

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

FGC:full gc執(zhí)行次數(shù)33 

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

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

 怎樣選擇工具   

     上面列舉的一些工具，各有利弊，其實如果在開發(fā)環(huán)境，使用什么樣的工具是無所謂的，只要能得到結(jié)果就好。但是在生產(chǎn)環(huán)境里，卻不能亂選擇，因為這些工具本 身就會耗費大量的系統(tǒng)資源，如果在一個生產(chǎn)服務(wù)器壓力很大的時候，貿(mào)然執(zhí)行這些工具，可能會

造成很意外的情況。最好不要在服務(wù)器本機監(jiān)控，遠(yuǎn)程監(jiān)控會比較 好一些，但是如果要遠(yuǎn)程監(jiān)控，服務(wù)器端的啟動腳本要加入一些jvm參數(shù)，例如用jconsloe遠(yuǎn)程監(jiān)控tomcat或jboss等，都需要設(shè)置jvm的 jmx參數(shù)，如果僅僅只是分析服務(wù)器的內(nèi)存分配和gc信息，強烈推薦，先用jmap導(dǎo)出服務(wù)器端的jvm的堆dump文件，然后再用jhat，或者 jvisualvm，或者eclipse內(nèi)存分析器來分析內(nèi)存狀況。