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

時間  2019-11-18
標籤 java heap space 解決 方法 jvm 參數 設置 欄目 Java 简体版
原文   原文鏈接 
    在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的堆棧設置過小的緣由。
跟據網上的答案大體有這兩種解決方法：
一、設置環境變量
set JAVA_OPTS= -Xms32m -Xmx512m
能夠根據本身機器的內存進行更改,但本人測試這種方法並無解決問題。多是還有哪裏須要設置。html

二、java -Xms32m -Xmx800m className
就是在執行JAVA類文件時加上這個參數，其中className是須要執行的確類名。（包括包名）
這個解決問題了。並且執行的速度比沒有設置的時候快不少。java

若是在測試的時候可能會用Eclispe 這時候就須要在Eclipse ->run -arguments 中的VM arguments 中輸入-Xms32m -Xmx800m這個參數就能夠了。linux


java.lang.OutOfMemoryError: Java heap space
===================================================程序員

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


在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佔用了更多的時間，而應用分配到的執行時間較少。windows

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」。tomcat

==========================================================
通過一個晚上的努力終於完成了一個文件替換指定字符串的程序，可是因爲我要替換的全站程序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"

jvm 內存查看與分析工具

業界有不少強大的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內存分析器來分析內存情況。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程