因?yàn)槌绦蛞獜臄?shù)據(jù)讀取近10W行記錄處理，當(dāng)讀到9W的時(shí)候就出現(xiàn) java.lang.OutOfMemoryError: Java heap space 這樣的錯(cuò)誤。

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

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

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

set JAVA_OPTS= -Xms32m -Xmx512m

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

2、java -Xms32m -Xmx800m className

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

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

如果在測試的時(shí)候可能會(huì)用Eclispe 這時(shí)候就需要在Eclipse ->run -arguments 中的VM arguments

中輸入-Xms32m -Xmx800m這個(gè)參數(shù)就可以了。

java.lang.OutOfMemoryError: Java heap space

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

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

java.lang.OutOfMemoryError: Java heap space

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

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

JVM在啟動(dòng)的時(shí)候會(huì)自動(dòng)設(shè)置Heap

size的值，其初始空間(即-Xms)是物理內(nèi)存的1/64，最大空間(-Xmx)是物理內(nèi)存的1/4。可以利用JVM提供的-Xmn -Xms

-Xmx等選項(xiàng)可進(jìn)行設(shè)置。

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

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

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

Heap size的 -Xms -Xmn 設(shè)置不要超出物理內(nèi)存的大小。否則會(huì)提示“Error occurred during

initialization of VM Could not reserve enough space for object heap”。

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

經(jīng)過一個(gè)晚上的努力終于完成了一個(gè)文件替換指定字符串的程序，但是由于我要替換的全站程序html文件太多，所以eclipse下邊老是在一個(gè)目錄結(jié)束后

報(bào)出java.lang.OutOfMemoryError: Java heap space的異常，然后就崩潰了。

我一想肯定是頻繁操作造成來不及回收，于是在每個(gè)循環(huán)之后加上一個(gè)Thread.sleep(1000),發(fā)現(xiàn)還是到那個(gè)目錄下就死掉，于是把

1000改成5000，還是到那里死掉，我想可能不是來不及回收這么簡單，或許sun 的JVM里邊剛好對(duì)于這種情況不釋放也有可能。

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

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

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

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

就可以被釋放。

(2)Java中提供了一些和垃圾收集打交道的類，而且提供了一種強(qiáng)行執(zhí)行垃圾收集的方法--調(diào)用System.gc()，但這同樣是個(gè)不確定

的方法。Java

中并不保證每次調(diào)用該方法就一定能夠啟動(dòng)垃圾收集，它只不過會(huì)向JVM發(fā)出這樣一個(gè)申請(qǐng)，到底是否真正執(zhí)行垃圾收集，一切都是個(gè)未知數(shù)。

(3)挑選適合自己的垃圾收集器。一般來說，如果系統(tǒng)沒有特殊和苛刻的性能要求，可以采用JVM的缺省選項(xiàng)。否則可以考慮使用有針對(duì)性的垃圾收

集器，比如增量收集器就比較適合實(shí)時(shí)性要求較高的系統(tǒng)之中。系統(tǒng)具有較高的配置，有比較多的閑置資源，可以考慮使用并行標(biāo)記/清除收集器。

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

(5)盡早釋放無用對(duì)象的引用。

大多數(shù)程序員在使用臨時(shí)變量的時(shí)候，都是讓引用變量在退出活動(dòng)域(scope)后，自動(dòng)設(shè)置為null，暗示垃圾收集器來收集該對(duì)象，還必須注意該引用的

對(duì)象是否被監(jiān)聽，如果有，則要去掉監(jiān)聽器，然后再賦空值。

就是說,對(duì)于頻繁申請(qǐng)內(nèi)存和釋放內(nèi)存的操作,還是自己控制一下比較好,但是System.gc()的方法不一定適用，最好使用finallize強(qiáng)

制執(zhí)行或者寫自己的finallize方法。

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

tomcat

遇到TOMCAT出錯(cuò)：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"

總結(jié)

以上是生活随笔為你收集整理的java heap 参数_java heap space解决方法和JVM参数设置的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。